Как работают приложения Сбербанк Онлайн: Workflow API и фрэймворки
Много кто пользуется приложением Сбербанк Онлайн, но немногие знают, как оно работает. Настало время приоткрыть завесу тайны – в этой статье мы расскажем о некоторых подходах, которые используем в разработке.
Здесь не будет биг даты, блокчейна, аджайла и другого рокет-сайенса. Зато будет описано API, на котором работают наши самые популярные приложения. Ценность этой статьи не в прорывных идеях, а в подходах и практиках, которые работают в большом приложении с одной из самых требовательных аудиторий.
Надеемся, что наш опыт поможет читателям сделать свой продукт лучше, а главное масштабируемым, потому что большинство шишек при разработке API мы уже поймали и исправили.
О чем пойдет речь
Мы расскажем, как в мобильном и веб приложениях Сбербанк Онлайн работают платежные сценарии, а именно про API между приложениями и сервер-сайдом.
Почему фокус на API? Все просто – это фактически единственный мостик, который соединяет клиентские приложения и бэкенд. Если проект небольшой, то мы можем легко менять API и переписывать под него приложения. Но если проект масштабный (такой, как у нас), то даже небольшие изменения API требуют вовлечения большого количества ресурсов как на фронте, так и на бэкенде, и становятся очень дорогими. И второй момент – чем раньше мы зафиксировали API, тем раньше фронтальные и бэковые команды могут начинать разработку. Им просто надо будет сойтись в одну точку.
Сначала мы немного расскажем о наших возможностях и ограничениях, чтобы было понятно, почему мы выбирали то, а не иное решение, а потом представим сам протокол API на верхнем уровне.
Специфика и мотивация
Приложения большие. Когда мы писали эту статью, приложение Сбербанк Онлайн на Android занимало около 800 000 строк кода, на iOS – 500 000 строк кода. И это только наш код, без подключаемых библиотек.
Обратная совместимость и много пользователей. MAU – 32 млн активных пользователей мобильного приложения. И если мы не сделаем обратную совместимость на уровне API, очень многим пользователям по всей стране придется качать приложения заново. Это очень нехорошо. Кстати, это одна из причин, почему у нас так много кода.
Сбербанк Онлайн разрабатывает много небольших команд. Вы, наверное, слышали про Agile в Сбербанке. Это правда, мы работаем по Agile в командах по 9 человек.
Приложение банковское: несмотря на то, что функциональность банковских приложений растет очень быстро, основное, что происходит в дистанционном банкинге – это последовательный процесс (обработка клиентских заявок). Такие процессы мы называем workflow. Заявки эти могут быть разного рода и обрабатываются они огромным количеством взаимосвязанных сервисов в периметре банка.
Два типа команд. Есть платформенные – они отвечают за разработку ядра приложения. И есть фичёвые команды – они создают прикладной функционал для конечных пользователей, используя архитектуру и инструменты, которые даёт платформа.
Омниканальность. Крайне важная история. Чтобы не разрабатывать бэк несколько раз – отдельно для мобильных приложений и отдельно, например, для веб-версии и банкоматов, нужно сделать так, чтобы API был максимально схожим для всех каналов (как минимум должна быть одинаковой структура ответа).
Мобильное приложение
Данные меняются динамически. Самые популярные операции в мобильном приложении – платёж и перевод. Реквизиты поставщиков услуг, набор полей, которые необходимо заполнить пользователю, – это динамическая информация, которая может часто меняться.
При этом пользователи могут не обновлять приложение, после того как установили его на устройство. Просто потому что могут. Чаще на это есть весомые причины, например, для обновления приложения нужно обновить версию ОС, а для этого купить новый телефон. Поэтому нам нужно решение, которое позволит менять данные без релиза приложения.
Мобильный интернет: наши приложения должны работать везде, даже где интернет нестабильный и медленный. Поэтому мы всегда боремся за размер и количество сообщений между мобильными приложениями и сервер-сайдом.
Лучший клиентский опыт: мы выбрали для себя основную технологию разработки мобильных приложений – разработка на нативных языках. Только так можно получить лучший клиентский опыт.
Если обобщить все эти требования – приложения должны разрабатываться на нативных языках, иметь повторно используемые компоненты внутри себя, но при этом вся бизнес-логика должна управляться со стороны сервера.
Как делать не стали
После того как мы обозначили граничные условия, расскажем, какие существующие решения мы анализировали.
Программирование на JSON
Логику проще описать императивно кодом, чем выдумывать (и изучать!) новый декларативный язык, который всегда будет ограничен сильнее, чем родной язык платформы. Кроме этого, надо предусмотреть песочницу, обработку ошибок, какой-то этап пилотирования – псевдокод должен постепенно распространяться на пользовательские устройства и при любых сбоях откатываться назад. Всё это усложняет разработку без ощутимых преимуществ.
Не используем описание стилей компонентов, поскольку они могут разниться от форм-фактора, платформы и даже режима работы (портретная/ландшафтная ориентация, responsive в web). Декларации стилей в конечной реализации всегда будут качественнее, ближе к реальности и корректнее работать с краевыми случаями. Кроме этого, бывает, что компоненты со схожей логикой принципиально по-разному работают на разных устройствах: например, ввод номера телефона – с телефонной книгой на мобильном устройстве и без неё в вебе.
Фиксация модели данных в интерфейсе приложения
Этот способ еще называется «прибить гвоздями». Смысл в том, что интерфейс приложения строится на уникальных идентификаторах объектов, которые передаются с сервера. В такой схеме любые изменения на стороне сервера приводят к переработкам клиентской части. Невозможно повторно использовать код. Сложно поддерживать.
Единственное, почему стоит выбирать такой способ на своем проекте, – уверенность на 99%, что API не будет меняться. Ну или если проект совсем небольшой и проектировать API дороже, чем быстро переделать пользовательский интерфейс под изменения в API.
Добавляем к каждому объекту признак стиля. UI приложений строим на основании этого признака. Стилей ограниченное число, поэтому появляется возможность строить интерфейс динамически. Но с увеличением функциональности UI приходится увеличивать количество стилей.
В этом варианте становится возможно управлять отображением отдельных элементов, но повышается сложность реализации связанности между разными полями. И главное – с ростом вариативности UI у вас будет постоянная необходимость расширять протокол API.
У JSON API детально описаны рекомендации по структурированию данных и описанию взаимосвязей между ними, но нет ничего, что могло бы описывать представление. Наша задача затрагивает в том числе визуальное расширение – добавление новых полей ввода, так что такой вариант нам не подходит.
Web Components / React Components API
Концепция веб-компонентов, которая в том числе значительно повлияла на API компонентов React, нам подходит уже намного лучше: с одной стороны, у нас есть контроль за отображением, с другой стороны – есть возможность привязывать данные к элементам UI.
К сожалению, всё слишком сильно завязано на HTML + CSS + JS. Напрямую не используешь, но запомним – потом пригодится.
Как решили делать
UI-контейнеры
Объекты упаковываются в контейнеры, презентационную логику приложения строим на этих контейнерах. Основное преимущество – можем группировать несколько простых объектов в один контейнер. Это дает свободу в программировании UX/UI на клиенте, например, можем управлять скрытием/отображением одного поля при заполнении данных в другом. При этом базовых типов объектов – ограниченное число, и весь бизнес-транспорт реализуется на них.
Мы выбрали именно этот подход. Сначала мы опишем протокол API, а потом – как устроены фрэймворки внутри мобильных и веб-приложений.
Чтобы было понятнее, рассмотрим API на примере простого процесса, например, перевод между своими счетами. Как добираемся до точки входа, не рассматриваем – это не процесс и для этого есть свой API (о нем мы тоже как-нибудь расскажем). Итого, процесс у нас начинается с точки входа:
/>
Транспорт данных
Для начала договоримся об основных принципах – как передаём данные. За основу возьмём самый простой подход – пары «ключ-значение». Ключом пусть будет строка из букв латинского алфавита, значение – тоже строки, но уже произвольные.
Формы для заполнения бывают сложные, с вложенными элементами и подразделами, значит, надо допускать вложенность. Можно именовать ключи в формате camelCase, но они могут быть плохо читаемым (например, в логах) или даже «портиться» в системах, нечувствительных к регистру. Нужно ввести разделитель.
Самый очевидный разделитель – точка – во многих языках используется для доступа к свойствам объекта. При неаккуратном использовании ключи с таким разделителем будут создавать словари (или объекты), в которых возможны коллизии. Например, “foo.bar” = “foobar” и “foo.bar.baz” = “foobarbaz” в javascript может повлечь перезапись свойства “bar” объекта “foo” со строки на объект. В конце концов, договорились на двоеточии: с одной стороны, явное визуальное разделение и семантическое отражение вложенности, с другой стороны, достаточно безопасно для всех используемых языков.
Что делать с повторяемыми полями? Вводим дополнительное правило: между парой разделителей могут быть либо латинские буквы, либо цифры. Получаются конструкции вида: children:5:name:first.
Пожив некоторое время с такой структурой, обнаруживаем ограничение: множественный выбор оказывается нетривиальным в реализации и требует дополнительных ухищрений на бэкэнде, чтобы держать высокую нагрузку.
Решение: значение – либо строка, либо список строк. Так решение выглядит типовым, но в то же время накладные расходы оказываются незначительными.
Шаг – это состояние процесса. Первый шаг у нас – выбор счета списания и счета зачисления и ввод суммы.
UI на этой картинке не видно, потому что шаг – это про серверную логику, а не про презентационную. Есть два подхода к работе с шагами: можно передавать с сервера только разницу (нарастающий итог в клиентском приложении) или каждый шаг целиком (нарастающий итог на сервере).
Анализ требований показал, что в ходе процесса экран может формироваться по-разному на разных шагах (ветвление процессов), поэтому вместо добавления управляющих команд для преобразования уже переданных сущностей проще каждый шаг передавать полностью таким, каким его должен увидеть пользователь.
Из дополнительных плюсов: при возврате к редактированию не нужно проигрывать весь сценарий или передавать дополнительный параметр “отдай всё”. При старте шага клиентское приложение сразу же получает всю нужную информацию для построения экранов.
Экраны
Экран – это разделение процесса на этапы в клиентском приложении. Как правило, экраны используются, чтобы форма была проще для восприятия. В нашем случае всё просто: один шаг – один экран.
Для экранов мы ввели два правила:
- переход между экранами может быть только линейным, без ветвлений;
- переход между экранами не требует взаимодействий с бэкэндом.
UI компоненты (блоки)
UI компонент – независимый компонент, который реализует клиентскую логику и наполняет документ данными. По сути, это ассоциация между управляющей командой в протоколе и куском кода и разметки в приложении. На первом экране три компонента:
- Счет списания
- Тот же компонент для счета зачисления
- Сумма перевода
Поля – это атомарные компоненты, которые выступают транспортом для отдельных элементов данных и обрабатывают пользовательский ввод в случае деградации блока. Типов полей ограниченное число и все они поддерживаются на уровне фрэймворка: text, checkbox, select, multiselect.
Это значит, что любая версия приложения может отрисовать интерфейс, опираясь только на типы полей.
Поля в UI-компонентах из нашего примера:
1. Поле со ссылкой на справочник в счете списания и счете зачисления. Почему ссылка на статический справочник? Потому что счет мы выбираем из списка карт (счетов), без лишнего обращения к серверу.
2. Два отдельных поля для суммы и валюты в компоненте ввода суммы
Таким образом, формат для полей имеет такую структуру:
События
Так как приложения ничего не знают о процессе, логично, чтобы события (кнопки, которые видит пользователь) тоже были частью ответа от сервера.
События мы разделили на два типа.
1) Основные – они есть почти на каждом экране в привычных местах для пользователя. Как пример, это события «назад» и «продолжить». Первое осуществляет переход на шаг назад, а второе собирает заполненные данные с клиентской формы и отправляет их на сервер вместе с командой «Перейти на следующий шаг».
2) И специальные – для нестандартных действий, которые мы заранее спрогнозировать не можем, да и смысла закладывать их в часть движка нет, так как они редко используются.
В нашем случае на экране только основные события – «продолжить» и «назад». Они реализованы на уровне платформы.
У всех событий есть ряд атрибутов, такие как сам тип события, title и признак видимости. И никакого UI на сервер-сайде вроде размера кнопки, положения и цвета. Эта логика реализуется на фронте.
Справочники
Со справочниками все стандартно. Если он небольшой, то мы его присылаем полностью в ответе от сервера и называем статическим. Сделано это для того, чтобы минимизировать количество запросов к сервер-сайду и время отклика на действие пользователя в интерфейсе. Чтобы его отобразить в форме на экране, добавляем поле с типом – selectList, одно из свойств которого – ссылка на статический справочник.
Если справочник большой, то он реализуется в виде отдельного rest-сервиса. В интерфейсе это выглядит как текстовое поле, по мере заполнения которого возвращается список возможных вариантов из справочника.
Ошибки валидации на клиенте и сервере
Так как основной элемент интерфейса – поле ввода данных, логично валидировать его на клиенте. Вместе с полями передаются правила валидации и сообщения, которые отображаются, если валидация не прошла.
Примерно так выглядит структура ответа:
Фрэймворки
Теперь немного о том, как с этим протоколом работают фрэймворки внутри приложений. Условно фрэймворки можно разделить на две основные части: workflow engine + обработчик UI-контейнеров. Такое разделение вызвано не только архитектурой приложений, но и организационной структурой. Движок разрабатывают и поддерживают платформенные команды, а UI-контейнеры фактически являются точками расширения и их программируют фичёвые команды. Таким образом, большему количеству команд не нужно вносить изменения в ядро.
Workflow engine
Движок внутри приложений (веб и мобильного) знает, что начался процесс работы с документом и что согласно протоколу ему придёт ряд атрибутов: шаги, экраны, UI-контейнеры и типы полей. На этих данных рисуется базовый интерфейс – нижнее и верхнее меню, основные кнопки, UI на простых типах полей, если они используются.
При этом движок не знает, сколько именно в сценарии будет шагов процесса, как шаги будут разбиты по экранам и какие там будут поля.
Если сценарий изменится, например, потребуется отобразить новое поле, то его будет достаточно добавить в ответ сервера, и клиентское приложение его отобразит. Для этого выпускать релиз фронтального приложения не потребуется.
Как работают UI-контейнеры?
Анализ потребностей дизайнеров и бизнес-заказчиков показал, что все потребности не получится удовлетворить простым расширением атрибутивного состава полей.
Поэтому нужны были точки расширения. Этими точками расширения стали UI-компоненты – это нативная реализация кода в самих приложениях, который идентифицируется движком по названию. По сути, это группировка поля/нескольких полей в логический блок, который может отображать кастомный UI. При этом модель данных протокола используются только для транспорта данных на бэкенд, весь UX и UI реализуется на стороне приложения.
Два режима работы фрэймворка
Когда движок парсит модель данных, он сравнивает список имен UI-контейнеров с реестром, который хранится внутри приложения. Если приложение не находит имени компоненты, то интерфейс строится на простых типах полей. Процесс будет полностью рабочим, но на стандартных UI-элементах.
Слева – как может отображаться контейнер для ввода суммы на списке из простых типов полей. Справа – если в сборке приложения есть UI-контейнер. Несмотря на то, что в режиме списка простых полей нет слайдера и есть отдельное поле вместо иконки с выбором валюты, – мы можем передать все данные с PL и процесс будет рабочим.
И тут мы получаем одно из основных преимуществ движка – доставить пользователю изменения без обновления приложения. В сборке есть маппинг имен компонентов на классы, в которых запрограммирован UI этих компонентов и пользовательский интерфейс строится на нем.
Каких правил мы стараемся придерживаться при работе с UI-компонентами:
- Поддерживать работу функционала в режиме списка простых типов полей. У любого прикладного проекта есть соблазн превратить динамический протокол в статический. Поэтому мы всех просим сначала разработать функционал на типовом UI-контейнере, а потом обогащать UX/UI добавлением кастомных контейнеров на этой модели данных. Это не только позволит в будущем обновлять процессы на старых сборках, но и автоматически поддерживает логическую целостность API.
- Не менять модель данных (JSON) для UI-контейнера, если он уже готов (проходит финальное тестирование или уже в продакшене). Так как логика на PL жестко связана с моделью данных, её изменение сломает функционал на версиях мобильного приложения, которые не обновляются. Тем не менее, модель можно расширять при условии сохранения обратной совместимости.
- Называть свой UI-компонент системным именем. Так как имя UI-компонента – обязательный атрибут протокола и должен быть минимум один на каждом экране, мы ввели специальное системное имя, которые реализует простой список полей.
- Не реализовывать бизнес-логику на UI-компонентах. Логику необходимо реализовывать на сервере, почему – писали выше.
Coming soon…
Мы очень старались писать лаконично, но это первая техническая статья про платформу Сбербанк Онлайн и она должна была многое охватить.
Пишите в комментариях, что непонятно, что интересно – постараемся писать меньше, но чаще и в цель. У нас много интересных вызовов, и поэтому много материала.
На чем сегодня работает Сбербанк и госорганы – обзор российской ОС Astra Linux
Звезда пленительного счастья или очередная черная дыра?
На днях Сбербанк объявил, что платформы сервиса «СберПро» теперь работают под управлением отечественной операционной системы Astra Linux. Изначально она создавалась в основном для использования в госорганах, а теперь становится заменой иностранных продуктов и для бизнес-предприятий. Рассказываем про плюсы и минусы двух ее версий.
Истоки «Астры»
Первые разговоры о российских аналогах западных систем пошли в стране еще в начале 2000-ных. Во времена кризиса 2008 года проблема импортозамещения уже стояла перед предприятиями, что в итоге вылилось в несколько крупных разработок. Одной из них была операционная система Astra Linux, базирующаяся на ядре свободно распространяемого «Линукса» (разработанного за границей, но это уже другая история).
Изначально система создавалась АО «НПО РусБИТех» для «оборонки» и предназначалась для комплексной защиты информации в целях силовых структур. Для этого уровень защиты информации, обрабатываемой ОС, был максимально высоким: вплоть до государственной тайны особой важности. В 2009 году она прошла сертификацию в Минобороны и ФСБ и смогла использоваться на самых защищенных военных и правительственных объектах.
Служащие ВС РФ за компьютерами, оснащенными Astra Linux (фото – минобороны.рф)
Стабильная работа – важнейший фактор для работы подобных операционных систем, возможно, поэтому вместо разработки собственных решений была использована база ОС с открытым кодом Linux. В отличие от Windows и MacOS, такая база позволяет собирать собственный дистрибутив, который управляется и настраивается конечным владельцем по своему усмотрению.
В качестве исходной ОС использовался дистрибутив Debian Linux, на тот момент считавшийся одним из самых стабильных и надежных. Astra Linux называется «официально признанной веткой» этого дистрибутива (как таковых признанных веток у Linux нет, но разработчики Debian признают существование Astra, что и отражено в статье по ссылке). Разработчик заявляет, что лицензионные соглашения на ОС разработаны в соответствии с законами Российской Федерации, но при этом «не противоречат духу и требованиям лицензии GPL».
Во второй половине 2010-х операционка попала в тренд импортозамещения и начала активно продвигать себя не только как продукт для государственных нужд. В частности, вышла версия универсальной ОС для персональных компьютеров. Кроме государственных предприятий «Астра» попала и на рабочие станции таких компаний как «Газпром», «РЖД» и теперь «Сбербанк». В 2018 году было заявлено, что Astra Linux адаптирована под российские процессоры «Эльбрус».
Astra Linux на российском ПК с иностранным монитором
Так что к лету 2022 года российская операционная система подошла с внушительным списком клиентов. Это не новодел и не наскоро собранный дистрибутив для импортозамещения в краткие сроки, а вполне себе рабочий инструмент, проверенный временем. Вопрос только в том, насколько этот инструмент хорош сам по себе. Давайте узнаем это, познакомившись с «внутренностями» продукта подробнее.
Astra Linux для рядового пользователя
Возвращаясь к новости про «Сбербанк», можно отметить, что холдинг предполагает работу не только конечных устройств, но и серверов под управлением «Астры», а это уже куда более серьезный переход. Российская ОС имеет серверную версию, которая используется для управления комплексами, системами и рабочими станциями.
Кроме того, дистрибутивы делятся на версии Common Edition и Special Edition. Первая представляет собой версию для «простого пользователя» (в рекламных материалах преподносится как версия для среднего и малого бизнеса). Вторая – уже обеспечивает необходимую защиту информации вплоть до уровня «Совершенно секретно» и предназначается для правительственных и других крупных организаций.
Версии ОС называются в честь российских городов-героев, например на 2022 год Common Edition именуется как «Орел», а Special Edition как «Смоленск».
На официальном сайте именно версия Special Edition выдается на главном экране «Продукты»
Нам будет интереснее познакомиться с версией для применения в домашних условиях. Тем более что сегодня Astra Linux называют альтернативой ОС Windows. Дистрибутив можно купить у партнеров компании, либо скачать на сайте компании или на одном из сайтов, найденных по соответствующему поисковому запросу. Скачать дистрибутив без лицензии можно бесплатно, но обновление, поддержка и доступ к официальным сервисам осуществляется на платной основе.
На официальном сайте найти ссылку на скачивание удалось далеко не сразу. Информация о Common Edition нашлась только на странице описания Special Edition после долгого скроллинга. На всякий случай дадим прямую ссылку на скачивание Astra Linux с официального сайта. Стоимость лицензии варьируется для каждого партнера/продавца. В частности, здесь удалось найти базовую за 4200 р. с поддержкой на год. Special Edition в базовом варианте можно купить за 8500 р. с поддержкой на 12 месяцев.
Разработчики сообщают о совместимости продукта с более чем тремя сотнями моделей отечественных и иностранных аппаратных устройств. Кроме того, утверждается, что система поддерживает все современные сетевые карты (а ей потребуется доступ в интернет во время установки и подключения). Минимальные системные требования: 1 ГБ ОЗУ и 4 ГБ на жестком диске, что достаточно адекватно для сегодняшних решений.
Начало установки Astra Linux Common Edition «Орел»
Установщик «Астры» имеет графический интерфейс, что делает его удобным для пользователя-новичка (в базовом варианте дистрибутивы «Линукса» не предполагают GUI). По внешнему виду он похож на установщик Debian, на котором и основан, но проще за счет отсутствия многих сложных параметров настройки.
Отзвуки «военного происхождения» можно увидеть уже на экране установки системы, например, по фразе «Операционная система общего назначения». Также мы видим изображение некоего микрорайона, возможно, как раз в Орле. В дальнейшем вам предстоит поработать еще с несколькими экранами, на которых настроить:
- параметры клавиатуры (это делается и в Windows);
- ПО, включаемое в систему по умолчанию – игры, поддержку сенсорного экрана, СУБД и так далее;
- представление компьютера в сетях – название, параметры доступа и т.п.;
- учетные записи и пароли к ним;
- разметку жесткого диска;
- системные параметры, характерные для ОС Linux (можно не использовать, если вы не слишком опытны в таких настройках).
Подробно ознакомиться с инструкцией по установке можно на официальном сайте ОС. После нее вам будет доступен рабочий стол системы и возможность наконец познакомиться с тем, что она собой представляет.
Рабочий стол Astra Linux
Графический интерфейс ОС неслабо напоминает Windows. Впрочем, если мы говорим об импортозамещении, то логично использовать именно знакомый большинству пользователей GUI.
Windows не продлят — Microsoft отключает ПО в России [обновлено]
Настройки Astra Linux производятся в панели управления (ее можно увидеть в меню «Пуск» на скриншоте выше) или через специальный терминал, характерный для Debian. Последнее предполагает базовые знания ОС Linux.
Панель управления для настройки операционной системы. Fly – это графический рабочий стол для Linux-систем
По умолчанию есть многие базовые приложения для комфортной работы, а также браузер Mozilla Firefox. Остальные программы можно установить дополнительно. Для этого в Debian используется утилита apt-get (установщик пакетов для работы в командной строке), но есть способ проще. В системе предустановлен менеджер пакетов Synaptic, с помощью которого вы увидите уже установленные пакеты программ и приложений, и сможете добавить свои.
Например, для установки популярного текстового редактора Emacs вам нужно будет найти его по названию в глобальной среде, отметить для установки и распаковать в Astra Linux. Как это сделать, вы можете увидеть в галерее ниже:
Устанавливаем редактор emacs на Astra Linux через Synaptic. Установленные пакеты в списке отмечаются зеленым квадратиком
Для работы с системой вам предстоит ознакомиться с тем, что такое Linux и какие приложения могут в нем работать. Почти для всех Windows-приложений есть аналоги, в которых еще нужно разобраться или хотя бы понять, какие вам доступны альтернативы.
Пользователи, впрочем, отмечают некоторую «бедность» репозитория Astra по сравнению с Debian и популярной Ubuntu. В отзывах о продукте говорится даже, что 30 % команд для Debian в российской версии работать не будут. Также говорится, что отечественная ОС больше подойдет для организаций, а не для рядового пользователя (этот термин опять отдает какой-то военной окраской). Тем не менее, у разработчика есть даже официальная инструкция о том, как установить на «Астру» Steam для получения компьютерных игр с этой популярнейшей платформы.
Что есть в системе по умолчанию:
- Базовый набор необходимых приложений, включая офисные (LibreOffice).
- Возможности для настройки системы и ее внешнего вида.
- Доступ в интернет (поддержка сетевых карт, предустановленный браузер) для закачки новых приложений и получения необходимых инструкций.
- Графический интерфейс, похожий на Windows.
- Возможности переключиться на планшетную и мобильную версии (поддержка сенсорных экранов).
- Файловый менеджер.
Что касается ощущения от работы, то в обзорах можно увидеть такое распространенное мнение:
Критично ли это для простого пользователя, который ранее работал только с Windows? Скорее всего, нет. Большинство пользователей не знают всех возможностей иностранной операционной системы, поэтому и в работе с «Астрой» вряд ли будут требовательны. Но вывод однозначен: прежде чем начинать работу, стоит немного изучить возможности Linux с графической средой.
Система для госорганов и корпораций
Теперь, когда мы разобрались с Common Edition, можно уделить внимание и корпоративным версиям с дополнительными возможностями.
Вряд ли эти отзывы писали продавцы лицензий на Windows. С другой стороны, с 2021 года система успела обновиться
Среди пользователей также можно встретить распространенное мнение, что ОС Astra Linux можно использовать только в рамках импортозамещения, если на рынке не будет ничего другого. Для госкомпаний работа с ней может стать вынужденным решением, даже при наличии рабочих иностранных аналогов, если будет выпущено постановление о переходе на отечественные ОС.
Непонятно, что входит в стоимость лицензии, жалуются пользователи. Зато можно примерно прикинуть цены на Astra Linux для корпоративного сегмента
Несмотря на невыигрышное для Astra Linux сравнение его с оригинальным Debian в плане репозитория, объем его все же выше, чем у многих других отечественных систем (ROSA, Title, RED OS и др.). Так что для корпоративного сегмента в нем можно найти всё что нужно для работы.
Разработчики обновляют и протоколы безопасности, например, последняя версия ОС получила раздельные механизмы защиты данных – теперь они работают независимо друг от друга и позволяют обеспечить необходимый контроль целостности программной среды. Система также получила возможность гарантированного удаления данных, чтобы исключить возможность их восстановления злоумышленниками.
В Astra Linux также работает механизм мандатного разграничения доступа. Если говорить простыми словами, то это система защиты, обеспечивающая доступ субъектов (пользователи/приложения и т.п.) к объектам (файлы/сайты/директории/части БД) на множестве различных уровней безопасности, которые невозможно «перемешать» между собой. Сама суть механизма не нова, но именно реализация произведена разработчиками «РусБИТех», и это одна из редких полностью отечественных доработок безопасности Linux-систем (чаще всего используются стандартные модификации SELinux – встроенной системы безопасности).
Естественно, что особое внимание уделяется и безопасности работы в интернете. Мандатное разграничение работает и здесь.
Страница из презентации Astra Linux, посвященная безопасной работе в сети
Последнее масштабное обновление ОС обещает стабильную, быструю и безопасную работу для предприятий любого уровня секретности. Есть отдельные негативные отзывы, но в целом работу в Astra Linux для госсектора можно назвать отвечающей современным требованиям.
Как заявляют разработчики, Astra Linux Special Edition 1.7 (она же «Смоленск») успешно прошла сертификацию СЗИ ФСТЭК России по самому высокому уровню доверия. Она официально полностью соответствует «Требованиям по безопасности информации, устанавливающим уровни доверия к средствам технической защиты информации и средствам обеспечения безопасности информационных технологий», а также «Требованиям безопасности информации к операционным системам» и «Профилю защиты операционных систем типа А первого класса защиты. ИТ.ОС.А1.ПЗ».
Таким образом, если не для «рядового пользователя», то для «подразделений» корпоративного сегмента система должна подойти неплохо.
Начался тест «Авроры» – первой российской операционной системы для смартфонов. Что о ней известно?
СБОЛ для Айфона: Новое веб-приложение Сбербанк Онлайн с поддержкой Touch ID и Face ID
С момента последнего удаления Сбербанк Онлайн из App Store Сбербанк активно работал над новыми версиями своего приложения, выпуская обновления под названием СБОЛ для iPhone. Тем не менее, каждое из этих обновлений также было систематически удалено Apple из магазина приложений.
Однако за последние три месяца Сбербанк сумел сделать заметный прогресс, создав полноценное веб-приложение Сбербанк Онлайн для Айфона, которое Apple не в состоянии удалить.
Новое веб-приложение Сбербанк Онлайн для iPhone
Основные функции банковского сервиса, такие как переводы через СБП, доступны в веб-приложении, а также сохраняется возможность оплаты услуг ЖКХ и пополнения баланса мобильного телефона. Веб-приложение также позволяет использовать контакты из телефонной книги пользователя для удобства переводов.
Приложение, хотя и обладает всеми основными функциями, все же несколько ограничено в своих возможностях. Например, он не поддерживает оплату через QR-код, в отличие от конкурента в лице Тинькофф Банка, и не отправляет push-уведомления. Но, учитывая, что устройства Apple поддерживают их, начиная с iOS 16.4, а также активное развитие Сбербанка Онлайн на платформе Android, можно ожидать, что эти недостатки будут исправлены в ближайшее время.
Однако, несмотря на эти недостатки, новое веб-приложение Сбербанк Онлайн предлагает ряд удобных функций. С его помощью можно быстро и легко входить в свою учетную запись с помощью Touch ID или Face ID, что делает его крайне удобным и безопасным для пользователей iPhone.
Веб-приложение можно легко установить на рабочий стол iPhone и использовать его в качестве полноценного приложения, без необходимости открывать браузер Safari. Кроме того, оно позволяет входить в учетную запись без ввода пароля, используя лишь данные биометрии, что упрощает и ускоряет процесс входа.
Как установить веб-приложение Сбербанк Онлайн наiPhone
Установка веб-приложения на iPhone довольно проста и не занимает много времени. Следуйте этим шагам:
- Откройте Safari на вашем iPhone и перейдите на https://online.sberbank.ru
- Когда сайт откроется, нажмите на кнопку «Поделиться». Это иконка, которая выглядит как квадрат с стрелкой, выходящей вверх, и она находится в нижней части экрана.
- В открывшемся меню прокрутите вниз и нажмите «На экран «Домой»».
- Здесь вы можете переименовать иконку приложения, если хотите.
- Нажмите «Добавить» в верхнем правом углу.
Теперь веб-приложение Сбербанк Онлайн должно быть установлено на вашем iPhone и видно на экране «Домой» в виде иконки, точно так же, как и любое другое приложение. Чтобы открыть его, просто нажмите на эту иконку.
Авторизация без пароля
Одной из ключевых функций нового приложения является возможность входа без пароля, используя Face ID или Touch ID. Это позволяет ускорить процесс входа и упрощает взаимодействие с приложением.
Как использовать веб-приложение Сбербанк Онлайн на iPhone без пароля с помощью Touch ID или Face ID
Использование веб-приложения Сбербанк Онлайн без пароля с помощью Touch ID или Face ID – это удобный и безопасный способ получить доступ к вашей учетной записи. Следуйте этим шагам:
- Добавьте веб-приложение Сбербанк Онлайн на рабочий стол вашего iPhone (если вы еще этого не сделали) и откройте его.
- Введите ваш логин и пароль. Если вы их не помните, переключитесь на вход по номеру телефона, введите его и нажмите «Восстановить доступ».
- Введите номер любой вашей карты Сбера и подтвердите вход паролем из СМС сообщения.
- Придумайте новый пароль для входа в Сбербанк Онлайн.
- Выполните вход в личный кабинет и дождитесь, когда веб-приложение само предложит вам активировать беспарольный вход. Если этого не произошло, откройте панель многозадачности, закройте Сбербанк Онлайн и повторно зайдите в личный кабинет. После этого сразу появится уведомление с предложением активировать вход по биометрии.
- Нажмите кнопку “Использовать” и подтвердите действие с помощью Touch ID или Face ID.
Теперь каждый раз, когда вы открываете веб-приложение Сбербанк Онлайн на iPhone, вы можете использовать биометрию для входа, и вам не нужно вводить логин и пароль.
В целом, новое веб-приложение Сбербанк Онлайн представляет собой значительное улучшение по сравнению с предыдущими версиями и ожидается, что его функционал будет дополнительно расширяться в будущем. Таким образом, новое веб-приложение Сбербанк Онлайн может стать прекрасной заменой как старому приложению Сбербанк Онлайн, так и более свежей версии СБОЛ для iPhone.
Автоматизированные системы Сбербанка
На июнь 2015 года «Сбербанк» делит свои автоматизированные системы по 11 основным направлениям:
- автоматизированные системы ядра (Core banking),
- системы FrontEnd,
- процессинговые системы,
- системы типа CRM,
- BI,
- кредитные системы,
- системы по управлению рисками,
- системы по управлению инвестициями,
- системы по управлению внутрихозяйственной деятельностью и персоналом,
- системы платформы BPM и
- системы ДБО.
Core banking
- АС ЦОД (автоматизированная система централизованного обслуживания вкладов физических лиц);
- АС BackOffice (централизованная база депозитов физлиц);
- AC УПД (управление платежными документами).
Данные системы предназначены для обслуживания розничного сектора клиентов «Сбербанка» и ориентированы, в первую очередь, на обслуживание физических лиц. В числе операций, которые выполняются с их помощью – обеспечение хранения счетов по вкладам физических лиц и данных о клиентах, обслуживание запросов структурных подразделений отделений о состоянии счетов по вкладам физических лиц, прием банковских транзакций от функциональных подсистем операционного уровня и др.
- АС Юпитер (хранение и обработка информации по зарплатным проектам);
- Корпоративная АБС автоматизации операций клиентов (юридических лиц и физических лиц, являющихся собственниками бизнеса);
- АС ГАММА (формирование бухгалтерских проводок на основании реестров сделок и платежных документов);
- АС Кассовый центр (решение, автоматизирующее процессы кассовых узлов и кассово-инкассаторских центров);
- АС Виват (система по учету и ведению военных пенсий);
- АС ТФиДО (глобальная платформа сопровождения торгового финансирования и документарных операций) ;
- АС Централизованная автоматизированная система ведения нормативно-справочной информации.
Системы FrontEnd
Одной из центральных систем данного блока является АС ФС, позволяющая выполнять функции администрирования офисом, приема платежей и переводов, погашения кредита физлиц, работы со счетами и вкладами, банковскими картами, сберегательными сертификатами и лотерейными билетами, денежными знаками и ценными бланками, валютными операциями, монетами и слитками из драгметаллов, кассовыми операциями.
Также к FrontEnd системам относятся:
- АС xBank (система банка, используемая для автоматизации работы операционных и кассовых работников в ВСП по вводу и обработке большинства операций розничного блока);
- АС Инфобанк (cистема для автоматизации операций по ценным бумагам «Сбербанка», дорожным чекам иностранных эмитентов, ведения централизованного реестра проблемных ценных бумаг);
- АС Сбор данных (сбор данных по кредитным обязательствам);
- АС Стоп-лист (ведение СТОП-ЛИСТов (террористы, недействительные документы, недобросовестные ссудозаёмщики), формирование транспортных файлов с реквизитами юридических и физических лиц, загрузка файлов журнала обращений и несоответствий);
- АС ВИК Договоры (ведение информации по договорам клиентов и базы данных юрлиц, заключивших со «Сбербанком» договор о зачислении денежных средств на счета физлиц);
- АС Банковское страхование, предназначенная для учета заявлений клиентов физлиц по страхованию;
- Веб-сайт «Сбербанка»;
- АС Dealing Manager (фронт-офисная система ведения позиции по сделкам на валютном, денежном и рынке драгметаллов);
- АС КВРБ (компенсации вкладчикам разорившихся банков);
- АС СББОЛ (СберБанкБизнесОнЛайн, предназначена для дистанционного управление счетами корпоративных клиентов посредством интернет браузера);
- АС Сбербанк Корпорация (внедрение комплексных продуктов по управлению финансовыми потоками крупнейших, крупных и средних клиентов банка);
- АС ЕФС (Единая Фронтальная Система), которая включает в себя всю фронтальную функциональность, связанную с автоматизацией обслуживания клиентов во всех каналах обслуживания и позволяет осуществлять кросс-канальные операции;
- АС Клиент Сбербанк, обеспечивающая электронный документооборот и удаленное управление счетами для клиентов — юридических лиц «Сбербанка» в Москве. Обслуживает порядка 300 000 клиентов (70 инсталляций).
Процессинговые системы
- АС WAY4 (процессинговая система банковских карт);
- АС SmartVista (фронтальная система, обеспечивающая онлайновое обслуживание авторизационных запросов по банковским картам и онлайновое взаимодействие с международными, и российскими платежными системами);
- АС ЕРКЦ (единый распределенный контактный центр «Сбербанка» на платформе Avaya для автоматизации справочно-информационного обслуживания, телемаркетинга, службы помощи банка);
- АС Запрос (шлюз запросов к внешним источникам информации);
- АС Masspay (система приема платежей, предназначенная для построения сети приема платежей населения с использованием устройств самообслуживания (банкоматы, информационные киоски);
- АС UPOS (универсальное ПО POS-терминалов и интегрированных кассовых решений в торгово-сервисных предприятиях эквайринговой сети «Сбербанка»);
- АС СПООБК2 (система предварительной обработки операций по банковским картам второго поколения). Обеспечивает предварительную обработку операций с кредитными картами. Автоматизация процессов, обеспечивающих подготовку и предварительную обработку операций по кредитным картам для последующей передачи данных в программно-аппаратный комплекс WAY4;
- АПК Matching — автоматизированная система, обеспечивающая формирование информации для проведения расчетов по банковским картам платежной системы MasterCard (карты, выпущенные сторонними банками), а также обеспечивающая формирование статистических и бухгалтерских отчетов;
- АС IQWAVE (Шлюз Платежных Транзакций). Для упрощения создания, внедрения и сопровождения интеграционных взаимодействий между автоматизированными системами «Сбербанка» и поставщиками услуг;
- АС ОПП (Обработка прямого потока). Предназначена для обработки файлов с информацией по выпуску/перевыпуску банковских карт, а также файлов с операциями пополнения/списания денежных средств по банковским картам.
- АС Дебаты 2.0. Система предназначена для ведения претензионной работы по банковским картам, включая проверку изменения статуса урегулирования претензии, наличия зарегистрированной претензии и регистрации претензии;
- АС СНУиЛ (система номерного учёта и логистики банковских карт и сопутствующих компонентов (Octopus). Обеспечивает мониторинг состояния всех видов банковских карт, учитывает количество израсходованных заготовок при производстве карты;
- Сценарии устройств самообслуживания (Сценарий УС) — сценарии работы устройства самообслуживания с центральной фронтальной системой для осуществления базовых клиентских операций с устройством – авторизации, выдачи и взноса наличных, работа с личным кабинетом, платежи и т.д.;
- ЕГПО (единое гибридное программное обеспечение, ПО устройств самообслуживания).
- АС CRM Розничный (система управления взаимоотношениями с клиентами розничного блока). В основе системы использован продукт Oracle Siebel CRM;
- АС CRM Корпоративный (система управление взаимоотношениями с корпоративными клиентами). Автоматизирует такие функции как создание единого представления о клиенте, управление сотрудничеством с клиентом, закрепление клиента за ответственным подразделением/сотрудником, разграничение доступа к клиентской информации;
- АС CRM Трансграничный (система управление взаимоотношениями с корпоративными клиентами банка, предназначена для автоматизации операций по работе с зарубежными корпоративными клиентами);
- АС MDM Клиентский (система на базе MDM для построения единого профиля клиента физического и юридического лица). Реализация на IBM InfoSphere MDM Server;
- АС MDM Продуктовый (централизованный каталог продуктов и тарифов). Реализация на IBM InfoSphere MDM Collaboration Server (бывший MDM Server for Product Information Management);
- АС ФКД (формирование кредитной документации). Осуществляет обеспечение достоверности и актуальности шаблонов кредитных документов;
- АС СУДИР (система управления доступом к информационным ресурсам);
- АС ФО Клиентов (финансовая отчетность клиентов). Информация из системы используется для формирования блоков кредитной заявки, приложений к кредитной заявке, блоков форм мониторинга, а также аналитической отчетности;
- АС Курсы валют (автоматизированная система установления валютных курсов и курсов драгоценных металлов по системе «Сбербанка»);
- АС GoldenSource (Котировки финансовых инструментов (КФИ)) источник мастер-котировок для финансовых целей;
- АС ЦАС ОК (Централизованная автоматизированная система Обращения клиентов) предназначена для регистрации обращений клиентов, классификации обращений, их обработки с возможностью передачи на экспертизу, подготовки и отправки ответа клиенту;
- АС MIS обеспечивает руководство банка аналитической информацией для принятия управленческих решений.
Фабрика данных
- Прогноз прироста данных на 2017 год – 28 Пб (сырых данных) -> 78 Тб в день [1]
- Объем хранения данных в Терадата
BI-системы
В «Сбербанке» существует Центр компетенции развития BI. По данным одного из выпусков корпоративной газеты для сотрудников «Сбербанк Технологии», в ведении центра находятся: программно-аппаратный комплекс Teradata, включающий аналитическое хранилище данных, оперативное хранилище данных Oracle Exadata и еще одна система – витрины MIS.
Управление метаданными
Основной целью создания единой базы метаданных является автоматизация и повышение качества бизнес-процессов [2] :
- Снижение стоимости анализа и проектирования решений
- Сокращение времени разработки и вывода кода на среды
- Повышение качества продуктов
- Контроль соответствия архитектурным требованиям
Подробнее о практическом применении управления метаданными в Сбербанке в отдельной статье.
Кредитные АС
- АБС для автоматизации операций кредитования физических лиц. Система включает операции кредитования физлиц, учет обеспечения по кредитам, учет резервов по кредитам, ведение части функционала позднего сбора по просроченной кредитной задолженности;
- АС Transact SM Розничный (автоматизация предкредитной обработки по физлицам). Система предназначена для ведения, хранения и обновления информации о кредитных продуктах, а также для решения задач документооборота и принятия решения по заявкам клиентов-физических лиц микросегмента малого бизнеса;
- АС Transact SM СМП (предкредитная обработка заявок по кредитованию собственников малого бизнеса). Система предназначена для ведения, хранения и обновления информации о кредитных продуктах, а также для решения задач документооборота и принятия решения по заявкам клиентов микросегмента малого бизнеса;
- АС Transact SM Экспресс-кредиты (система, позволяющая вводить, обрабатывать, хранить и выполнять поиск информации о клиентах и заявках на кредит в централизованной базе данных);
- АС Централизованная ИАС Кредитование юридических лиц (централизованное ведение вкладов физических лиц с проведением централизованных зачислений и обеспечением межфилиальных операций). Система используется для проведения операций по счетам физических лиц, содержит актуальные остатки по счетам физических лиц;
- АС Централизованная ИАС Кредитования физических лиц (обслуживание кредитных договоров физических лиц (фронт, мидл и бэк офис). Помимо потребительских, авто и ипотечных кредитов в системе также обслуживаются разрешенные овердрафты карточных счетов;
- АС Tallyman (система для сбора просроченной задолженности);
- АС Hunter (предупреждения о мошенничестве при рассмотрении кредитных заявок). Система проводит сравнение данных по вновь оформляемой кредитной заявке с уже имеющимися заявками с целью определения и предупреждения мошенничества;
- АС ОКИ (система для оценки кредитных историй);
- АС Калита (сбор просроченной задолженности физлиц и малого-микро бизнеса). Данная система может взаимодействовать с внешними системами с целью информирования должника о наличии просроченной задолженности с использованием различных каналов; с системами госорганов (ФССП) для реализации судебного и исполнительного производства, с коллекторскими агенствами при передаче на сопровождение/продаже просроченного портфеля и др.
АС по управлению рисками
- Аналитический модуль расчета лимитов и рейтингов (АМРЛиРТ) — рейтинговая модель оценки вероятности дефолта контрагента. Рассчитывает вероятность дефолта и рейтинг заемщика, ожидаемые потери при дефолте заёмщика, кредитоёмкость, внутренний рейтинг;
- АС СУОР (Система управления операционными рисками) — учет анализ, управление операционными рисками, своевременное выявление потенциальных угроз, снижения потерь при реализации операционных рисков;
- СУККР (система управления корпоративными кредитными рисками). Предназначена для управление рисками корпоративного кредитного портфеля для решения таких бизнес-задач как прогноз уровня кредитных рисков с формированием и поддержкой базы данных по реализованным кредитным рискам, оценка рисков совокупного кредитного портфеля банка, контроль качества кредитного портфеля банка, проведение стресс-тестирования кредитного портфеля банка и др.;
- Автоматизированная система поведенческого скоринга для работы с просроченной задолженностью. Обеспечивает снижение расходов на мероприятия, связанные с взысканиями задолженности за счет проведения анализа поведенческих, статических и социально-демографических характеристик клиентов и учета результатов этого анализа при определении стратегии взыскания;
- Система контроля качества андеррайтинга (СККА). Обеспечивает сбор и анализ информации о работе андеррайтеров банка, внутренний аудит качества работы кредитных подразделений;
- Обеспечение гибкого механизма управления структурой лимитов риска, в т.ч. при условии дальнейшего усложнения методологии Автоматический расчет сумм лимитов различных типов в зависимости от факторов, определенных методологией Банка.
- SAP Bank Analyzer Limit Manager. Обеспечивает гибкий механизм управления структурой лимитов риска, расчет сумм лимитов различных типов и др.;
- АС Казначейство (комплексная автоматизированная система казначейства на единой платформе).
АС по управлению инвестициями
- АС DiasoftCUSTODY 5NT. Система предназначена для автоматизации функций первичного учета и сопровождения операций на фондовых рынках в рамках собственного портфеля центрального аппарата, портфелей территориальных банков и отделений банка в Москве, операций брокерского обслуживания и доверительного управления активами клиентов;
- АС DiasoftDEALING 5NT. Система обеспечивает автоматизацию функций первичного учета и сопровождения казначейских операций центрального аппарата «Сбербанка» на денежных рынках и на рынках драгметаллов;
- АС Дивиденд. Предназначена для бухгалтерского учета процесса выплаты дивидендов;
- АС Реестр акционеров (ведение реестра акционеров «Сбербанка», проведение собрания акционеров);
- АИС Депозитарий 2000. Система обеспечивает автоматизацию депозитария в части учета выпусков ценных бумаг, проведения бухгалтерских операций с ценными бумагами; хранение информации об эмитентах ценных бумаг и депонентах и др.;
- АС Murex (консолидированный риск трейдинга, P&L — консолидированный риск трейдинга и P&L — фронт-офис);
- АС QUIK (система электронной торговли для клиентов брокерского обслуживания). Предоставляет доступ клиентам к торговле на фондовом, денежном и срочных рынках через веб или полноценный клиент;
- АС ЦБДБО (централизованная база договоров брокерского обслуживания);
- АС FX&MM Plus — занесение заявок корпоративных клиентов на размещение денежных средств в депозиты, векселя, сделок бронирования, а также привлечение кредитов, требующих согласования с департаментом казначейских операций и финансовых рынков, установления процентной ставки, акцептования, хранения и анализа информации по всем заявкам и сделкам с корпоративными клиентами, а также операций на валютном рынке;
- АС eFX (стратегическая мультипродуктовая система электронной торговли Apama);
- АС Фокус (фронт-офисная система казначейства на фондовом рынке, брокерское обслуживание клиентов на фондовом рынке);
- АС SavEx – (электронная площадка для проведения торговых операций с внутренними подразделениями (территориальными банками «Сбербанка» и отделениями Москвы) и внешними клиентами;
- АСУ ОВП (автоматизированная система управления открытой валютной позицией);
- АС Calypso (TDS) — система продуктового учета внебиржевых деривативов;
- АС Удаленное рабочее место депонента (ЛУЧ) — рабочее место для обеспечения электронного документооборота c «Национальным Депозитарным Центром» для исполнения поручений «Сбербанка» на ММВБ.
АС по управлению внутрихозяйственной деятельностью и персоналом
- Единая АС управления персоналом на базе SAP HCM;
- Управление внутрихозяйственной деятельностью на базе SAP ERP.
АС платформы BPM
Создание BPM-системы полного цикла в сбербанке
Единая модель процесса
- Модель, единая для всех. В АРИСе модель процесса является единой для всех потребителей, от владельца процесса до разработчика и исполнителя
- Согласованные изменения. Если при изменении процесса на нижнем уровне автоматизация) выявляется несоответствие верхнему уровню, при необходимости меняется верхний уровень
- Контроль качества. Передача результатов моделирования на следующий этап обеспечивается после автоматизированной проверки показателей качества модели процесса
Система связанных процессов
- Репозиторий. Все модели процессов размещаются в едином репозитории (АРИС)
- Связанные процессы. При моделировании процесса осуществляется его связывание с используемыми процессами
- Контракт процесса. Для каждого используемого процесса публикуется его контракт, в рамках которого гарантируются свойства процесса и обеспечивается обратная совместимость
- Связанное изменение. Для каждого процесса при выполнении изменений учитываются его зависимости от других процессов
E2E-процессы вместо Продуктовых процессов Разделение процессов на 2 уровня:
- E2E-процесс — процесс оказания услуги потребителю (от заявки до результата) — показывает порядок действий по обслуживанию потребителя
- Продуктовый процесс (процессы жизненного цикла экземпляра продукта, ПЖЦ) — процесс, показывающий использование E2Eпроцессов в разных состояниях продукта и для перехода между состояниями
Концентрация на E2E-процессах для повышения ценности для клиентов:
- реинжиниринг и трансформация
- непрерывное улучшение
Контроль продуктовых процессов — позволяет убедиться в целостности жизненного цикла продукта