Сентябрь 2020

ELMA4: онлайн-презентация новых возможностей

В феврале 2020 года компания ELMA анонсировала выпуск low-code платформы для быстрого создания корпоративных приложений — ELMA4. Мы рады представить релиз ELMA 4.0

На презентации:

  • покажем, что появилось в ELMA4;
  • расскажем, как low-code инструменты уже сейчас
    помогают нашим клиентам меняться легче;
  • ответим на вопросы.

Будьте в курсе технических новинок лидеров рынка BPMS в России и СНГ!

https://www.elma-bpm.ru/elma4/

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

В настоящий момент существует несколько конкурирующих стандартов для моделирования бизнес-процессов. Нотация управления бизнес-процессами (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 используется программистами, чтение обычными пользователями затруднительно.

IBM BPM

Стек платформ IBM представляют собой Java enterprise приложения, запускаемые на сервере websphere application server.

IBM BPM имеет следующие элементы:

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

IBM BPM состоит из следующих частей:

Репозиторий процессов — хранит всю информацию о процессах, сервисах, структурах данных и т.п.;

  1. Process server — исполняющий компонент, обеспечивающий работу бизнес-процессов;
  2. Process center — компонент, обеспечивающий доступ к репозиторию процессов для разработки;
  3. Process designer — среда разработки, основанная на eclipse;
  4. Портал — среда работы конечных пользователей (может не использоваться);
  5. Process data warehouse — хранилище статистической информации о прохождении экземпляров процессов;
  6. Blueworks Live — облачный сервис по моделированию и документированию бизнес-процессов. Построенная модель может быть импортирована в process designer, но на практике эта возможность используется редко.


IBM BPM имеет следующие уровни лицензий:

  • Express — содержит все описанные выше компоненты BPM, но ограничен только одним проектом. Возможно установить только на одиночный сервер, без возможности кластеризации.
  • Standard — содержит все описанные выше компоненты BPM. Позволяет запускать сразу несколько проектов, позволяет установить на кластеризованный сервер, базовая поддержка интеграции.
  • Advanced — содержит дополнительно встроенную шину данных и расширенные средства для интеграции. Предназначен для высоконагруженных проектов.

IBM имеет различные сопряженные продукты:

  • ODM — платформа для бизнес-правил;
  • Case manager — платформа для создания и организации набора кейсов;
  • Integration bus — интеграционная шина.

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

При внедрении решения на IBM BPM предполагается следующий подход:

  1. Выбрать проект, который показывает наилучший баланс между объемом затрат и потенциальным эффектом;
  2. Описать бизнес-цели в BlueworksLive;
  3. Описать бизнес-процесс в BlueworksLive;
  4. Провести серию встреч с пользователями для прогона процесса, описанного в BlueworksLive (так называемый Playback 0);
  5. Перенести процесс из BlueworksLive в Process Center для начала разработки;
  6. Далее итерационно:
    1. Разработать часть бизнес-процесса;
    1. Показать результаты пользователям (Playback 1..N).

Разработка и исполнение бизнес-процессов в 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 адреса организации используют те, которые выделяет ЦБ РФ для конкретной организации.

Разработка модуля создания финансовых сообщений «Передатчик ПС БР»

В рамках программного модуля «Передатчик ПС БР» предполагается реализовать следующий функционал:

  • создание финансовых сообщений в формате УФЭБС ED101;
  • создание финансовых сообщений в формате УФЭБС ED501;
  • создание финансовых сообщений в формате SWIFT MT101;
  • хранение финансовых сообщений в базе данных;
  • выгрузка платёжных поручений в pdf формате;
  • обработка принятых входящих сообщений;

Данный модуль можно считать практически полноценной АБС.  Сформированные в АБС реестры будут отправляться в АРМ КБР (автоматизированное рабочее место клиента Банка России) — специальный компьютер в банке в отдельном защищённом контуре, с которого уходят платежи в ЦБ РФ. 

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

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

Разработка приложения будет осуществляться в Visual Studio 2017. В качестве хранилища данных будет использоваться MS SQL Server 2019.

Версии программы будут храниться в системе хранения версий – GitHub, репозиторий https://github.com/aovakur/Peredatchik_PSBR. Количество веток – две (master и release). В ветку мастер я буду выкладывать доработанные формы и функции, в ветку релиз буду выкладывать собранный релиз со всеми библиотеками и необходимыми таблицами. 

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

Разработанное подключение к БД представлено на рисунке 3.3. Имя и пароль пользователя будет скрыто от пользователя. По умолчанию имя пользователя – adminkbr, пароль aA12345678.

Данные для подключения будут храниться в классе DBUtils.cs, инициализация подключения будет происходить в классе DBSQLServerUtils.cs.

Глобальные настройки подключения к БД я установлю в файле app.config.

Доступ к глобальным настройкам будет происходить через СonfigurationManager и вызов функции ReadSetting, обновление через функцию AddUpdateAppSettings.

Счётчик сообщений (ed501, ed101) в течение операционного дня (текущего дня) также будет задан через глобальные настройки:

<add key=»currentday» value=»20200416″ />

<add key=»EDNo» value=»2″ />

<add key=»MessageName» value=»10836708462″ />

<add key=»MessageIDED501″ value=»2″ />

<add key=»MessageIDED501_full» value=»10836708462_pain_MSG_20200416_00000002″ />

 Если текущий операционной день поменялся, то происходит обнуление счётчика и первому ЭС присваивается номер 1.

Для разработки и тестирования программы я буду использовать локальный Microsoft SQL Server 2019, в будущем таблицу можно будет перенести на облачный сервер или сервер БД в организации.

Подключение к БД будет осуществлять по TCP соединению и 1433 порту. Для работы с MS SQL я буду использовать Microsoft SQL Server Management studio 2018.

Для отображения созданных и принятых электронных сообщений необходимо создать экранную форму (DataGrid).

Форма 1 будет формироваться в классе Form1.cs. Для сохранения платёжного поручения в специализированный формат необходимо разработать глобальные настройки сохранения. Настройки сохранения будут формироваться в классе settings.cs.

Для создания платёжного поручения (форма 0401060 согласно Приложению 2 Положения Банка России от 19 июня 2012 года № 383-П «О правилах осуществления перевода денежных средств» (в редакции Указаний Банка России от 15.07.2013 № 3025-У, от 29.04.2014 № 3248-У, от 19.05.2015 № 3641-У, от 06.11.2015 N 3844-У, от 05.07.2017 N 4449-У и от 11.10.2018 N 4930-У)) необходимо разработать специальный пользовательский интерфейс и механизм автоматического формирования некоторых полей.

Пользовательский интерфейс формы №0401060 представлен ниже

Данная форма является основным функционалом системы, после создания платёжного поручения его реквизиты можно передать в БД, сформировать PDF документ, отправить на печать, сохранить в соответствующий формат (ed101, ed501, MT101). Форма формируется в классе Form2.cs и используя класс pp.cs для создания нового экземпляра класса CreatePP, значения полей будет заполняться через модификатор доступа get и set. Для каждого поля ПП присвоен соответствующее название P1-P110 c модификатором доступа public и переменные p1-110 с модификатором доступа private.

Фрагмент кода приведён ниже:  

private string p1;

private string p0;

private int p2;

private int p3;

private string p4;

private string p5;

public string P0

        {

            get { return p0; }

            set { p0 = value; }

        }

        public int P20

        {

            get { return p20; }

            set { p20 = value; }

        }

        public string Status

        {

            get { return status; }

            set { status = «Новое»; }

        }

        public string P1

        {

            get { return p1; }

            set { p1 = «Платежное поручение»; }

        }

       public string Date_pp()

        {

            DateTime dt = DateTime.Now;

            string curDate = dt.ToShortDateString();

            return curDate;

        }

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

Фрагмент кода для проверки поля:

if (textBox10.Text == «»)

{

textBox10.BackColor = Color.Fuchsia;

}

После вызова функции «create_pdf» будет формироваться pdf документ с заполненными полями

В функцию «create_pdf» в качестве параметров будут передаваться значения полей, c помощью fields. SetField данные значения будут проставляться в PDF документ.

Фрагмент кода приведён ниже:

public string Pdf(string p0, string p4, string p6, string p60, string p102, int p7, string p8, string p9, string p10, string p11, string p12, int p101, string p13, string p14, string p15, string p17, string p18, string p61, string p103, string p16, int p21, string p24, string p5, string p22, string p104, string p105, string p106, string p107, string p108, string p109, string p110)

        {  string pathsafe = settings.safepathpdf + p4 + «_» + p0 + «.pdf»;

            string pathsafetemplatefont = settings.safepath + «\\Template\\Tahoma.ttf»;

            BaseFont baseFont = BaseFont.CreateFont(pathsafetemplatefont, BaseFont.IDENTITY_H, BaseFont.NOT_EMBEDDED);

            PdfReader template = new PdfReader(settings.safepathetemplate);

            PdfStamper stamper = new PdfStamper(template, new FileStream(pathsafe, FileMode.Create));

            AcroFields fields = stamper.AcroFields;

            fields.AddSubstitutionFont(baseFont);

            fields.SetField(«p4», p4);

            fields.SetField(«p3», p0);

            fields.SetField(«p6», p6);

Большинство полей автоматизированы и не требуют участие пользователя.

Автоматически формируется сумма пропью (согласно требованиям ЦБ), подтягивается банк плательщик, плательщик, получатель, банк получателя. По наименованию организации проставляется ИНН, КПП; по наименованию банка проставляется БИК, корреспондентский счёт.

Производим установку и запуск программы «Передатчик ПС БР» от имени пользователя. Заполняем поля платёжного поручения

Формируем документ ED101 и анализируем результат сохранения

C помощью XMLPAD проводим сопоставление нашего файла ED101 и его XSD схемы.

Наш созданный файл ED101 не имеет логических ошибок и может быть успешно перенесён в АРМ КБР (АРМ КБР СПФС) для отправки в ЦБ РФ.

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

следующем образом:

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

<ED501 xmlns=»urn:cbr-ru:ed:v2.0″ EDAuthor=»3510108000″ EDDate=»2014-09-22″ EDNo=»900004″ ActualReceiver =»3510106000″>

<ProprietoryDocument >QT4+MUk1PTg1IDcwOj40OEA+MjA9PT41ICAyIGJhc2U2NA==</ProprietoryDocument></ED501>

где ProprietoryDocument – подписанный документ.

Осуществляем отправку сформированного сообщения через АРМ КБР/ АРМ КБР СПФС в платёжный контур ЦБ РФ.

После отправки ЭС ED101/ED501 я получил ответную квитанцию от ЦБ РФ о о следующем статусе:

<?xml version=»1.0″ encoding=»utf-8″?><soapenv:Envelope xmlns:soapenv=»http://www.w3.org/2003/05/soap-envelope»><soapenv:Header><props:MessageInfo xmlns:props=»urn:cbr-ru:msg:props:v1.3″><props:To>uic:452500055555</props:To><props:From>uic:KBRGATE</props:From><props:MessageID>KBRGATE_guid:786df05a239943f3bc9eca41a6fc430a</props:MessageID><props:CorrelationMessageID>guid:786df05a239943f3bc9eca41a6fc430a</props:CorrelationMessageID><props:MessageType>3</props:MessageType><props:Priority>5</props:Priority><props:CreateTime>2019-08-06T07:46:04Z</props:CreateTime><props:SendTime>2019-08-06T07:46:04Z</props:SendTime></props:MessageInfo><props:AcknowledgementInfo xmlns:props=»urn:cbr-ru:msg:props:v1.3″><props:AcknowledgementType>2</props:AcknowledgementType><props:ResultCode>0000</props:ResultCode><props:ResultText>ЭС поступило в ТШ КБР:uic:777777700011. Информация о исходном сообщении: имя файла: ED997_06104603.dat. Адресная информация исходного сообщения: логический адрес отправителя: uic:452500055555, логический адрес получателя: uic:777777700011. Время формирования квитанции: 2019-08-06 07:46:04</props:ResultText>

</props:AcknowledgementInfo></soapenv:Header><soapenv:Body></soapenv:Body></soapenv:Envelope>

Поля имеют следующую расшифровку:

  • CorrelationMessageID – исходное сообщение, сформированное АРМ КБР;
  • ResultCode – код статуса (000 – успешно, 001 — неуспешно),
  • ResultText – сам статус ЭС (успешно поступило в ТШ, обработано, исполнено).

Ссылка на разработку https://businessarchitecture.ru/test-spfs

Клиент-серверное приложение, язык разработки C#, база данных MS SQL

Скачать программу можно по ссылке https://sourceforge.net/projects/peredatchikpsbr/

Тестовая база данных http://developcbs.ru/downloads/ps_bankrussia_test.bak

Скачать дистрибутив http://developcbs.ru/downloads/Setup.msi
E-mail для связи: andrey@businessarchitecture.ru,

Телефон: +7 (930) 946-81-61 (Андрей)

Концепция BPM

Для обозначения моделирования управленческой и производственной деятельности используют термин «бизнес-процесс». В терминологии стандартов системы менеджмента качества международного стандарта ISO 9000 версии 2008 года используется термин «процесс». Развитие и распространение обеих областей знания постепенно привело к сближению этих понятий и развитию методик и анализа бизнес-процессов. Сейчас методики моделирования и анализа бизнес-процессов являются одним из важнейших инструментов, используемых в настоящее время для повышения эффективности бизнеса.

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

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

Современные системы управления базируются на следующих основных подходах: TQM, PIQS, стандарты ИСО серии 9000, которые регламентируют требования к системам менеджмента качества.

Информационные технологии используют большинство систем TQM, PIQS, BPMS, ERP.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На предприятии запускается система BPM. Для начала в систему сотрудникам закладывается на обработку договора среднее время, которое они тратят на эту работу на момент запуска. Конвейер начинает действовать. Затем время уменьшают — скорость «ленты» увеличивается. Растёт и производительность труда. При этом всегда видно, сколько сотрудников не справляется с графиком. Если не успевают единицы — их можно уволить и взять более проворных. Если же неуспевающих много — надо разбираться, может, скорость конвейера целесообразно снизить.

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

Мир, описанный Куртом Воннегутом в антиутопии «Механическое пианино», становится все ближе. И уже не кажется антиутопией. Автоматизация на порядок повышает производительность труда. Вот и еще путь снижения издержек производства.

Несколько лет назад перед руководством немецкой компании Knorr-Bremse, которая имеет семь заводов в Германии и занимающейся выпуском тормозных систем, была поставлена задача внедрить систему менеджмента качества. Эта система должна была базироваться на реальных процессах. Не секрет, что требования стандартов ИСО 9000:2000 допускают возможность формальной сертификации, то есть предприятие может показать, что удовлетворяет требованиям стандарта, при этом, однако, реальные улучшения процессов осуществляться не будут. Насколько можно судить по отчетам менеджеров верхнего уровня Knorr-Bremse, эта компания пошла по пути реальной работы с процессами. На первом этапе были определены девять основных бизнес-процессов, которые затем были детализированы до 46 процессов. После этого команда из 108 сотрудников различных заводов компании занималась описанием этих процессов и разработкой документации системы менеджмента качества. Вся работа заняла около полутора лет. Итогом работы стала сеть описанных бизнес-процессов компании и документация системы менеджмента качества, основанная на этих процессах.

Некоторые компании, например, российское представительство L’Oreal Luxe использует простейшие программные средства типа MS Visio и MS Exсel для рисования диаграмм бизнес-процессов и вносит в таблицу данные о их прохождении. Но это работает только в простейших случаях и небольших компаниях. В компании MTS используется BPM система, но в отдельных подразделениях используется Visio или Бизнес студио для описания неисполняемых бизнес-процессов. В конечном счете для полноценной работы нужно использовать специализированные ВPM-системы.

В России первые BPM системы начали внедрять несколько лет. В результате внедрения BPMS в Альфа-Банке была установлена платформа Pega, являющаяся одной из лучших систем класса BPM и подходящая для автоматизации всех поставленных задач, для привлечения клиентов на зарплатные проекты и централизации информации. Данный проект стал победителем конкурса Global CIO «Проект года-2014» в номинации «Лучшее решение в предметной области/BPM».

Внедрение BPM поможет:

  1. Ликвидировать разрыв между функциональность ERP и повседневными задачами сотрудников;
  2. Наладить обмен данным между корпоративными приложениями, базами данных;
  3. Найти баланс между тиражируемыми системами, собственными и заказными разработками;
  4. Настроить интеграцию между собственными системами и системами бизнес-партнеров;

Электронная подпись и криптопровайдеры

Система разграничения доступа к информации должна содержать четыре функциональных блока:

  • Идентификацию и аутентификацию субъектов доступа;
  • Диспетчер доступа;
  • Криптографическое преобразование информации при ее хранении и передаче;
  • Очистка памяти;

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

Электронная подпись (ЭП) — это программно-криптографическое средство. Оно обеспечивает проверку целостности документов, устанавливает лицо, которые его отправило, проверяет целостность.

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

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

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

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

Электронные подписи разделяются федеральным законом «Об электронной подписи» от 06.04.2011 N 63-ФЗ [17]:

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

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

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

В России инфраструктура открытых ключей доступна всем желающим. Изначально она была создана агентством Росинформтехнологии на базе Общероссийского государственного информационного центра (ОГИЦ). Однако сейчас федеральный удостоверяющий центр передан в ведение «Ростелекома». Этот телекоммуникационный оператор активно предлагает развивать различные проекты с использованием инфраструктуры открытых ключей.  

Электронная подпись в электронном документе равнозначна собственноручной подписи на бумажном документе при следующих условиях:

  • сертификат ключа пользователя не утратил силу;
  • осуществлена проверка подлинности электронной подписи в документе;
  • электронная подпись используется в соответствии со сведениями, указанными в открытом сертификате пользователя;

У каждого ключа электронной подписи существует UID, который определяет область применения электронной подписи.

Расширенная область действия ключа для финансовых документов ЦБ РФ имеет следующие значения:

1.3.6.1.4.1.10244.5.1.1.5 — UID

1.3.6.1.4.1.10244.5.1.2.2 — UID

1.3.6.1.4.1.3670.5.10.15- UID

Процесс создания цифровой подписи состоит из следующих шагов:

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

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

Федеральный закон «Об электронной подписи» от 06.04.2011 N 63-ФЗ регулирует отношения в гражданско-правовых области, оказании государственных и муниципальных услуг, исполнении государственных и муниципальных функций, при совершении иных юридически значимых действий, в том числе в случаях, установленных другими федеральными законами.

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

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

  1. Обязательная аккредитация. В 2019 году она стала обязательным условием для подключения к крупным системам электронного документооборота (например, сайт Госуслуги, mos.ru и тд);
  2. Техническая совместимость применяемых программно-аппаратных средств для генерации и верификации ЭЦП (USB-носители, ПО) с устройствами, которыми пользуются заявители (ПК, ноутбуками, смартфонами, планшетами) и установленными на них операционными системами;
  3. Гарантия уникальности используемых идентификаторов: объектов, номеров электронной подписи и закрытых ключей;

В работе рассматриваются аккредитованные средства криптографической защиты информации: программно-аппаратный комплекс «Валидата УЦ», СКАД Сигнатура, Крипто Про CSP.

АПК «Валидата УЦ» — отечественная реализация инфраструктуры открытых ключей, реализована с использованием международных рекомендаций и стандартов: X.509 версии 3, RFC 5280, PKCS#10, PKCS#7. АПК «Валидата УЦ» имеет Сертификат соответствия ФСБ (СФ/128-2880) [18].

Представляет собой комплекс программных средств:

  • центр сертификации;
  • центр регистрации;
  • сертифицированное ФСБ криптографическое ядро СКЗИ «Валидата CSP»

АПК «Валидата Клиент» входит в состав АПК «Валидата УЦ»  и являтся  клиентским программным средством криптографической защиты информации, предназначенное для установки на рабочее место пользователя. Имеет Сертификаты соответствия ФСБ России СФ/114-2810 и СФ/124-2811. Представляет собой локальный справочник сертификатов пользователя и криптографическое ядро СКЗИ «Валидата CSP».

На основе Web-сервера разработана система «Транзит»  (система защищённого обмена электронными документами на основе квалифицированной электронной подписи), в нее так же водит криптографическое ядро СКЗИ «Валидата CSP».

Для защиты электронной почты разработаны средстава семейства «Курьер», которые используют СКЗИ «Валидата CSP» и входят в АПК «Валидата Клиент».

АПК «Валидата Клиент» на основе файлового обмена :

  • Автоматизированный клиент СКЗИ МБ предназначен для клиентов Московской Биржи. Позволяет автоматизировать обработку подписанных и зашифрованных файлов, которыми они обмениваются с Московской Биржей, на уровне файловых каталогов.
  • Автоматизированный клиент СКЗИ Сигнатура предназначен для клиентов Центрального банка Российской Федерации. Позволяет автоматизировать обработку подписанных и зашифрованных (со сжатием) файлов при использовании СКАД «Сигнатура».

Криптографические алгоритмы АПК «Валидата Клиент» представлены в таблице

Электронная подписьГОСТ Р 34.10-2012, ГОСТ Р 34.10-2001
Хэш-функцииГОСТ Р 34.11-2012, ГОСТ Р 34.11-94
ШифрованиеГОСТ 28147-89

«СКАД Сигнатура» разработана компанией ООО «Валидата» по заказу Банка России и предназначенное для защиты информации в платежной системе Банка России. Данного СКЗИ распространяется Банком России только среди участников его платежной системы. К отличительным особенностям данного СКЗИ можно отнести:

  1. Данное СКЗИ реализует собственную инфраструктуру открытых ключей. Справочник открытых ключей содержит сертификаты пользователя, список доверенных и отозванных сертификатов, криптографически защищен на закрытом ключе пользователя. Без ведома пользователя невозможно установить доверенный сертификат в хранилище.
    СКЗИ Верба-OW реализует схожую ключевую модель.
  2. Ключи создаются децентрализованы с помощью участников обмена, в качестве центра сертификации выступает Банк России;
  3. СКЗИ поддерживает работу с функционально-ключевыми носителями (vdToken);

Криптографические ключи, используемые для взаимодействия с платежной системой Банка России, бывают трех видов: только шифрование; шифрование и подписание; шифрование, подписание и наложение транспортной подписи;

Криптографические алгоритмы СКАД Сигнатура представлены в таблице 2.6.

Таблица 2.6  — Криптографические алгоритмы СКАД Синатура

Электронная подписьГОСТ Р 34.10-2012, ГОСТ Р 34.10-2001
Хэш-функцииГОСТ Р 34.11-2012, ГОСТ Р 34.11-94
ШифрованиеГОСТ Р 34.12-2015

Для обмена финансовых сообщений с ЦБ РФ будет использоваться ЭП по алгоритму ГОСТ Р 34.10-2012 и хэш-функция ГОСТ Р 34.11-2012.

Компания КриптоПро создана в 2000 году и в настоящее время занимает лидирующее положение по распространению средств криптографической защиты информации и электронной цифровой подписи. Основное направление деятельности компании — разработка средств криптографической защиты информации и развитие Инфраструктуры Открытых Ключей (Public Key Infrastructure) на основе использования международных рекомендаций и российских криптографических алгоритмов.Продукты компании распространяют более 850 юридических лиц на основании дилерских договоров. Компания выдала более 4 000 000 лицензий на использование СКЗИ КриптоПро CSP и свыше 800 лицензий на использование удостоверяющего центра КриптоПро УЦ, которые применяются различными государственными и коммерческими организациями в системах электронного документооборота, а также востребованы при построении глобальных общегосударственных информационных систем.

КриптоПро CSP 5.0 разработан компанией КриптоПро. Кроме КриптоПро CSP 5.0 у компании еще есть решение КриптоПро ФКН CSP/Рутокен CSP (не извлекаемые ключи на токенах с защищенным обменом сообщениями) и облачная версия — КриптоПро DSS (ключи в облаке) [19].

КриптоПро CSP 5.0  одна из последних разработок компании, в ней поддерживается широкий список платформ, алгоритмов, улучшено быстродействие, удобный пользовательский интерфейс. Работа со всеми ключевыми носителями в связке с  КриптоПро DSS и КриптоПро ФКН CSP/Рутокен CSP теперь единообразна. Для переведа разработанных АБС компаний и переход на новую версию КриптоПро  не требуется переработка и доработка, API и интерфейс остается единым.

Назначение КриптоПро CSP:

  • Создание и проверка ЭП;
  • Осуществление шифрования и имитозащиты;
  • Обеспечение защищенного соединения по протоколам TLS, и IPsec;
  • Контроль системного и прикладного программного обеспечения для защиты от НСД;

В КриптоПро CSP 5.0 реализованы не только актуальные криптографические алгоритмы, но еще и возможность использования привычных носителей для хранения секретных ключей RSA и ECDSA.

Криптографические алгоритмы КриптоПро CSP 5.0 представлены в таблице.

Электронная подписьГОСТ Р 34.10-2012, ГОСТ Р 34.10-2001, ECDSA, RSA
Хэш-функцииГОСТ Р 34.11-2012, ГОСТ Р 34.11-94, SHA-1, SHA-2
ШифрованиеГОСТ Р 34.12-2015 («Кузнечик» — начиная с 5.0 R2), ГОСТ 28147-89, AES (128/192/256), 3DES, 3DES-112, DES, RC2, RC4

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

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

Многие пользователи КриптоПро хотят работать с не извлекаемыми носителями информации, но не повышать их до уровня функционального ключего носителя, для них специально была добавлена поддержка популярных носителей Рутокен (ЭЦП 2.0, JaCarta-2 ГОСТ и InfoCrypt VPN-Key-TLS). Дополнительно пользователи могут работать с токенами и смарт-картами без криптографических сопроцессоров (Gemalto/SafeNet, Multisoft, NovaCard, Rosan, Alioth, MorphoKST и СмартПарк и тд).

Кроме поддержки ключей на носителях также реализовано хранение ключей в реестре Windows, на жестком диске, флеш-накопителях на различных платформах.

Новый набор на стажировку: начни карьеру в «Лаборатория Касперского» уже сегодня!

На связи «Лаборатория Касперского». Давненько мы с тобой не виделись!
Прошёл целый год — сумасшедший и непредсказуемый. Но мы стабильны как никогда и запускаем очередную волну набора на программу стажировок SafeBoard!
Уже бегу регистрироваться!
Ладно, мы лукавим: 2020-й — год нововведений и для нас тоже. Вот основные изменения в программе:
 
Отбор — быстрее. Раньше стажеры выходили на работу в феврале; в этот раз они приступят к задачам уже в конце ноября.
 
Направлений — больше. Если ты наконец выучил пять стандартных стримов программы, поздравляем: теперь их 11. И, кстати, теперь мы не только про IT: нам нужны все — от дизайнеров до продакт-менеджеров.
 
Формат — гибче. Для самых крупных направлений — массовый отбор, чтобы выбрать лучших из лучших. Там, где команд меньше — индивидуальная работа с каждым кандидатом после онлайн-этапа.
 
Слишком много новой информации?
Тогда приходи на наш онлайн-митап 26 сентября, где мы все расставим по полочкам.
Ответим на все вопросы, расскажем, как увеличить шансы попадания на стажировку, и позовём экспертов сразу нескольких направлений. Каждый из них тоже был студентом вуза, каждому нужно было учиться новому, преодолевать страхи и принимать много решений — и каждый готов рассказать свою историю уже в ближайшую субботу.
 
А чтобы начать собственную — нужно сделать первый шаг. Действуй!