Прежде, чем объединяться, нам надо решительно размежеваться (Business continuity management vs Business Process Continuity vs Dependability in technics)

Синонимы: Надежность в процессах = надежность процессов = надежность операций = операционная надежность (с учетом синонимии словосочетаниями «сущ. + сущ.» [Морф23]).

En: dependability, reliability, resilience (availability, stability) Business Process. Непрерывность процессов — в контексте «business continuity» (Business Process Continuity, BPC) и т. п.

Методологические вводные: текст будет обнадежен от типовых угроз (распространенных рисков):

1. простые вещи делаем сложными, т. е. простое формализуем через сложные конструкции (излишнее нагромождение), что часто или необоснованно («овчинка выделки не стоит») или является диверсией, как видимо, определение операционной надежности (operational resilience») в п. 1.4 716П.

2. сложные вещи плохо декомпозируем: не верно разбиваем на простые составляющие;

3. одно и тоже называем разными словами, а разные вещи — одним термином.

1. Процесс и надёжность

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

Процесс

В общем случае, синонимы: делание, процесс, операция, функция, действие, активность (activity), см. правильный «Business Process Management», например, книжки ARIS или [BPM23] – там все подробно показано.

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

Например, термин «операционный процесс» имеет значение только если его дать явно. Без конкретизации это будет равносильно «операционная операция» (масло масляное).

Надежность

Это тоже простой термин, но его (впрочем, как и «процесс») долго усложняли, история показана в «Таблица 1. Определения термина „надежность“ в советских документах» [Depend1].

«Надежность в процессах» (надежность процессов) и «Надежность в технике» [27.002] имеет одну природу, в первом случае под термином «объект, изделие, система» подразумевается «процесс». Например, в Приложении 2 [27.003] требования по надежности содержат:

• Вероятность выпуска заданного количества продукции определенного качества за смену;

• Вероятность выполнения типовой задачи за заданное время.

Это все показатели, определяющие надежность процесса.

«Объекты, изделия, системы» — бывают статические и динамические, последние — это и есть процесс.

Что же такое надёжность? Не будем смотреть современные учебник и ГОСТ, там как правило пошли по пути «а», см. «Методологические вводные». Открываем Ушакова «Справочник по расчету надежности» [Ушаков66]:

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

Заменим «устройство» (его в последующих ГОСТ как раз меняли на «объект, изделие, система») на «процесс» и получим: Надёжность процесса — это свойство процесса выполнять требуемую операцию (функцию, задачу). Еще проще: надёжность процесса (операции) — это его способность функционировать (оперировать, выполняться). И это было изначально в 1962 году: Надежность — свойство системы выполнять задание, см. рассказ об истории термина «надежность» [Depend1]. Также см. один из вариантов определения: «способность (объекта, — читай процесса) функционировать как и когда требуется», т. е. как способность процесса — выполняться («главное процесс») и выполняться с успешным результатом («главное результат»).

Важно сделать два уточнения [Depend1]:

1. речь идет о режиме использования устройства \ процесса по назначению (освещать темный подъезд — электрическая лампочка, а не яркий монитор ЭВМ), т. е. те режимы, которые определены в ТУ (технические условия) на изделие \ процесс, включая «нештатные» сценарии, но формализованные в рамках процесса;

2. «потребителя, пользователя, заказчика интересует только конечный результат, вне зависимости от причин, по которым он может быть не достигнут (где „собственная“ надежность объекта является только одной из них), такая интерпретация МС (международным стандартом IEC 60 050–192/Ed. 1. International Electrotechnical Vocabulary — Part 192: Dependability) может представляться вполне оправданной с точки зрения конечного потребителя, не разбирающегося глубоко в проблемах надежности». т. е. рассматривается (определяется) весь спектр воздействующих на процесс негативных факторов.

Однако такого определения недостаточно, т.к. определение должно отвечать на вопрос: «сколько вешать в граммах?», т. е. способность должна быть измерима. В этом нам поможет теория вероятностей. Как она работает может посмотреть каждый: бросаем монету много‑много раз и убеждаемся, что в среднем (примерно) будет выпадать равное число орлов и решек: ровная закономерность вероятностей обоих событий.

Однако прикладную теорию надёжности под себя «подмял» риск‑менеджмент, а его в свою очередь управление качеством (ISO 9000), притом с замахом на «всеобщее» (TQM). Начало было положено в 1993 через двойные стандарты МЭК 300–1 / ИСО 9000–4 и это называлась: гармонизация стандартов МЭК по управлению надежностью (серия 300) и стандартов ИСО по управлению качеством (серия 9000) [Depend3]. В заставке к статье обыгрывается обратный путь («возвращение к истокам»): От Управления качеством к Управлению надежностью.

Загадочный риск

Риск — это вероятность события, взвешенная на тяжесть последствия (возможная опасность). Мы не говорим: «риск выигрыша», а только «риск проигрыша». Если при броске монеты определить, что орел — это проигрыш, то можно употребить термин «риск»: риск проигрыша = риск выпадения орла.

Таким образом, риск — это всего лишь вероятность чего — то плохого (негативного последствия, «на свой риск и страх»). Если мы не любим зиму, то численно «риск наступления зимы после осени» будет равен 1. Вероятность неизбежного события = 1, а невозможного = 0.

Перепишем определение «надежность процесса» с учетом риск ориентированности:

Надежность процесса — это его способность противостоять действующим на него негативным факторам. Количественно надежность процесса — это интегральная оценка его рисков, выраженных количественно. Кстати, если риск — это уже вероятность чего‑либо, то бессмысленного говорить «вероятность риска» (вероятность вероятности).

Надежность оценивается через показатели надёжности, которые обычно характеризуют позитив (т. е. обратное риску), например, вероятность безотказной работы процесса (функционирование процесса) против «риск отказа». Коэффициент готовности процесса (функция готовности) — это вероятность застать процесс в состоянии «процесс исправен». В 1960 Дж. Хосфорд ввел термин dependability [Depend1]: вероятность того, что система будет способна функционировать, когда это требуется.

Критерий отказа

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

• использование более надежных элементов системы;

• резервирование элементов (отказоустойчивость) как структурное, так и временнОе;

• смягчение критерия отказа.

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

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

Важно понимать, что одни отказы влияют на остановку процесса, другие на его результативность (брак). Сбой может привести как к увеличению времени изготовления единицы продукта (сервиса) с удовлетворение предельного срока, так и с неприемлемой просрочкой (SLA), а может одновременно результат переводить в разряд «брак» по техническим параметрам (ТУ).

Качество алгоритма

Уберем из рассмотрения параметра «эффективность» стоимость ресурсов и будем оценивать эффективность (качество) алгоритма процесса. В бизнес‑процессе «Бросок монеты», эффективность алгоритма будет 1, а результативность 0,5, т.к. результат будет всегда половина (условие орёл — брак или наоборот) и он не зависит от квалификации исполнителя и качества материала. В других процессах мы можем повышать эффективность алгоритма путем резервирования, например, количеством контрольных процедур.

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

1 — это идеальный исполнитель (работает безошибочно);

0 — абсолютный халтурщик.

2. Надежность в процессах

2.1 Окружение «Надежность в процессах»

Внедрение понятия «Надежность в процессах» (как элемента BPM, Business Process Management) — это попытка отсечь область между «большим \ необъятным BCM» (Business continuity management) см. [BCOR23] и «Надежность в технике». Под такую «Механику процессов» (инженерия процессов — как инструмент / framework корпоративных архитекторов) в части количественной оценки надежности бизнес‑процессов можно составить что‑то типа «Справочник по расчету надежности бизнес‑процессов». Варианты названий разные: «Надежность процессов и операций», «Операционная надежность», «Непрерывность бизнес‑процессов», «Процессный BCM» (инженерный BCM) и иной Mgmt (хотя слово «management» \ «управление» в названиях чего‑либо мне не нравится).

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

Ниже домена «Надежность в процессах» расположен этаж — домен систем — автоматизированных и неавтоматизированных (технические и механические средства, здания, рабочие места). При расчетах надежности они играют ключевую роль и при этом обеспечивая «транзит» надежностных характеристик оборудования в домен «Надежность в технике» [27.002]. Для примера отказоустойчивый кластер (Fault Tolerant Cluster) — это область «Надежность в технике». Еще есть домен «информация» с областью «надежность информации».

Такое размежевание (отсечение «всеобъемлющего BCM» и «Надежность в ИТ‑системах») — из заповеди \ эпиграфа к статье подчеркивает, что целостную картину обеспечения непрерывности бизнеса \ процессов \ систем нужно смотреть через призму, образованную изоляцией соответствующих контейнеров.

Рассмотрим различие отказа ИТ‑системы и процесса на примере инцидента и RTO (Recovery Time Objective, целевое время восстановления) ИТ‑системы \ процесса.

Клиент приходит в офис банка чтобы положить деньги на счет (расчетный или депозит) или осуществить перевод средств, внесенных наличкой. В это время ломается автоматизированная система банка (АБС). С позиции ИТ‑системы банка, произошел инцидент «отказ АБС» и все айтишники бросились чинить АБС и пытаться уложиться в RTO. С точки зрения процесса клиентского обслуживания отказа не было (была лишь деградация сервиса): деньги принимаются, выдаются приходники, поручения клиента складываются в стопку, а отражение поступивших средств на счете будет проведено после починки АБС. С переводом средств времени у банка может оказаться еще больше, т.к. условия банковского обслуживания иногда предусматривают фразу: «Не позднее следующего операционного дня». Таким образом, на уровне «процессов» (Надежность в процессах) в части указанной номенклатура процессов — отказа вообще не было (все условия договора банковского обслуживания выполнены), в то время как на уровне «систем» (Надежность в технике) произошел критический отказ, т.к. остановилось «сердце» банка.

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

Иногда подобное декларируется как: клиенту не нужно видеть (знать) «подноготную» процесса, ему важен только результат процесса.

Рассмотрим «Надежность в процессах» на примере структурного резервирования в процессах. Допустим нужно оплатить процент по кредиту. При попытке войти на сайт через домашний компьютер был обнаружен обрыв кабеля к провайдеру («последняя миля»). Попытка войти через мобильное приложение также не увенчалось успехом, например, из‑за необходимости обновления приложения, а само приложение было удалено из соответствующего store из‑за санкций. В итоге, берем чемодан с деньгами и идем в ближайший банк.

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

Изоляция слоев обеспечения непрерывности (надежности) проводится через создание контейнеров для каждого слоя по типу вложенной матрешки (как и в OSI layer, Open Systems Interconnection). Как пример размежевания «Надежность в процессах» и «Надежность в технике» рассмотрим рис. …. На котором показана общая матрешка из процесса и его обеспечивающих ИТ‑компонент.

Примером может быть моделирование сквозной цепочки компонент: процесс (подпроцесс) — Прикладная система — инфраструктурные элементы. Даже когда в финансовой компании нет полноценной CMDB это обязывает регулятор строить руками, например, при формировании формы 0 409 072 — отчет по операционной надежности из 6406-У (для финансовых кредитных и не кредитных организаций). Наиболее ценное в форме — это набор длинных и непонятных строчек, содержащих смысл, показанный на рис. 2.1 (немного поправлено из [TAB24]).

Сложной для понимания строкой (можно было сделать понятнее, человеко‑читаемо) в форме 0 409 072 кодируется (18-МР Приложение 1) последовательность необходимых систем и инфраструктурных элементов для выполнения бизнес‑процесса «ХХХ» (не соответствует рис. 2.1):

ТпрКО8|Lekton Classic|ОУ|БфКО22|Фронт‑офисная система учета с использованием пластиковых карт|lekton|Урв1|АС1|АС2|Windows 10|Прин1| Ри2|microsoft|21H2|Клсо99|Клс1|840|Не применимо|Лиц9|Арх3.1|Не применимо|Закуп5|Поддерж4|Авт1|Обнв4|Уязв1|Упр1|ФСТЭК9|Не применимо|ФСБ9|Не применимо|Отсутствует|Не применимо|Отсутствует

РацПредложение: создать онлайн калькулятор или on‑premises (open source), который из понятной таблички будет формировать как схему (рис. 2.1), так и причудливую строку для формы 0 409 072. Общий механизм реализации показан в [SmartDesign24], т.к. генерация схемы из таблицы через промежуточный dot \ graphviz. Таким образом, будет практическая польза для BPM\ EA от GRC («Управление рисками в соответствии с требованиями регулирующих органов») 787П / 779П / 6406-У — раз финансовым организациям все равно собирать и сдавать 0 409 072 форму, то можно одновременно с минимальными затратами предоставить корпоративным архитекторам (Enterprise Architecture) инструмент визуализации архитектуры прямо с привязкой к бизнес‑процессам компании.

2.2 Состав процесса

Определим «Процесс» как функцию с аргументами:

• входящее обеспечение (вход) — входные элементы, включая материалы, заготовки, внешние сервисы;

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

Для упрощения будем считать, что сама функция задается только алгоритмическим обеспечением, выраженным через workflow & docflow. Функцию с аргументами см. рис. 2.2:

В таблицах рис. 2.2 обыгрывается эталон качества, выраженный в девятках. Таблица слева это коэффициент готовности (показатель класса BPC, Business Process Continuity) — как вероятность застать систему (процесс) в работоспособном состоянии: как хорошо процесс работает, без учета его результата (его результативности). Например, «пять девяток непрерывности» (готовности) составляет простой в 5,25 минут в год (525 600 минут), что равноценно 10 минутам простоя на один миллион минут (чуть менее двух лет). Сравните этот же показатель с «числом сигм» («six sigma», Motorola, LSS), определяющий качество изделий, продукции, результата процесса, из правой таблицы рис. 2.2: те же «пять девяток», но уже качества — результативности.

3. Результативность процесса

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

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

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

Результативность измеряют разнообразными величинами:% годных и сквозной выход годных, дефектов на единицу (PPM) и дефектов на миллион возможностей (DPMO), количество сигм (Sigma Short Term) и Z‑score (Z table), а также Ср‑СрК, Рр‑РрК и другими.

Бизнес‑процесс «Подбрасывание честной монеты». Допустим, по ТУ решка соответствует условиям, а орёл — брак.

Результативность процесса по «процент годных» будет в среднем 0,5. Стоимость ресурсов не рассматриваем, поэтому про эффективность сказать ничего нельзя.

DPMO = 500 000. «Количество сигм» из Приложение A (справочное) ГОСТ Р ИСО 13 053–1–2013 даст значение ровно 1,5 сигмы, а Z.bench = 0 (разница в 1,5 сигма).

Подробнее расчет см. в lean‑группе ТГ, включая дотошное обсуждение пресловутой дельты в 1,5 сигмы.

Оценку показателей воспроизводимости и пригодности процесса см. в одноименном ГОСТ. Расчет процента выхода годных изделий по данным каждой операции см. формулу.

Чтобы поддерживать процесс в стабильном статистически управляемом состоянии используют методы статистического управления процессами, например, контрольные карты, которые отражают текущее состояние процесса, дают оценку степени изменчивости процесса, определяют наличие статистической управляемости, см. ГОСТ Р 50 779.42 «Статистические методы. Контрольные карты Шухарта».

Понятие результат иногда определяется как «выходной эффект» (ГОСТ 27.003).

В «процессном домене» лежат результативность (степень достижения результата) и эффективность (цена / затраты достижения результата), но второй — уже вне области значений «надежность процесса». Востребованность результата на рынке (спрос продукции компании) — это уже домен «организация» (не домен «процессы») и область значений «надежность организации». На данном этаже («процессном домене») важно лишь чтобы процесс соответствовал ТУ и SLA и его надежность определяется на основе лишь их требований (как корреляция с заданными значениями).

4. Вопросы

4.1 Вопрос по существу: дайте ссылку, если что‑то подобное обсуждалось, т. е. «скрещивание» BPM и теории надежности, выделение понятия «Надежность процессов» и систематизация подходов.

4.2 Вопрос Меркантильный, но практический:

поделитесь примерами обязательных для финансовых компаний документов, закрывающих (или раскрывающих) реализацию требований 787П / 779П, что‑то типа «Политика обеспечения Операционной надежности» (обезличка, шаблоны, «рыба» и т. п.).

Посоветуйте форумы \ ТГ‑каналы (желательно не вендорные), где идет обсуждение этих «шедевров» «кровавого» Enterprise ruGRC №.787/779П.

Есть ли ИИ модель, до обученная СТО БР хххх, ГОСТ Р 57 580.3–2022 — ГОСТ Р 57 580.4–2022 и 719П / 787П / 779П и т. п.?

4.3 Что из западного Best Practice наиболее близко и подробно описывает (напоминает) серию ГОСТ: Р 57 580.1/2/3/4

Имеется ввиду не разнообразные общие концепции «всеобъемлющего» BCM (BS 25 999, ISO и т. п.), а откуда этот конкретный «копи‑паст» (фрагменты текста) или все же аналогов нет?

Вместо заключения. Выше показан общий подход, концепция «Надежность в процессах» с примерами. Также не встречал ранее сопоставления «пять девяток непрерывности» (готовность системы, простой в 5,25 минут в год) с «числом сигм» («six sigma», Motorola, LSS), по сути «пять девяток качества». В целом, это про количественное выражение «главное процесс» (простой в минутах) vs «главное результат» (качество в сигмах).

В следующий раз надеемся увидеть показатели «надежности процесса» класса «Business Process Continuity» и их расчет.