Прежде, чем объединяться, нам надо решительно размежеваться: 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) и т. п.
Методологические вводные: текст будет обнадежен от типовых угроз (распространенных рисков):
простые вещи делаем сложными, т. е. простое формализуем через сложные конструкции (излишнее нагромождение), что часто или необоснованно («овчинка выделки не стоит») или является диверсией, как видимо, определение операционной надежности (operational resilience») в п. 1.4 716П.
сложные вещи плохо декомпозируем: не верно разбиваем на простые составляющие;
одно и тоже называем разными словами, а разные вещи — одним термином.
1. Процесс и надёжность
Процесс и надёжность – два очень простых термина. Далее под процессом будем понимать «бизнес-процесс», который в отличие от природного процесса (химические, физические процессы) реализуется не природой, а «человеко-машиной», т.е. в общем случае – «рукотворные» (искусственный, артефакт).
Процесс
В общем случае, синонимы: делание, процесс, операция, функция, действие, активность (activity), см. правильный «Business Process Management», например, книжки ARIS или [BPM23] – там все подробно показано.
- Когда я беру слово, оно означает то, что я хочу, не больше и не меньше, - сказал Шалтай презрительно.
Например, термин «операционный процесс» имеет значение только когда его явно определить, т.к. без конкретизации это будет равносильно «операционная операция» (масло масляное).
Надежность
Это тоже простой термин, но его (впрочем, как и «процесс») долго усложняли, история показана в «Таблица 1. Определения термина „надежность“ в советских документах» [Depend1].
«Надежность в процессах» (надежность процессов) и «Надежность в технике» [27.002] имеет одну природу, в первом случае под термином «объект, изделие, система» подразумевается «процесс». Например, в Приложении 2 [27.003] требования по надежности содержат:
Вероятность выпуска заданного количества продукции определенного качества за смену;
Вероятность выполнения типовой задачи за заданное время.
Это все показатели, определяющие надежность процесса.
«Объекты, изделия, системы» — бывают статические и динамические, последние — это и есть процесс.
Что же такое надёжность? Не будем смотреть современные учебник и ГОСТ, там как правило пошли по пути «а», см. «Методологические вводные». Открываем Ушакова «Справочник по расчету надежности» [Ушаков66]:
Надежность — свойство устройства, обеспечивающее выполнение им требуемой задачи в установленном для него объеме в определённых условиях эксплуатации.
Заменим «устройство» (его в последующих ГОСТ как раз меняли на «объект, изделие, система») на «процесс» и получим: Надёжность процесса — это свойство процесса выполнять требуемую операцию (функцию, задачу). Еще проще: надёжность процесса (операции) — это его способность функционировать (оперировать, выполняться). И это было изначально в 1962 году: Надежность — свойство системы выполнять задание, см. рассказ об истории термина «надежность» [Depend1]. Также см. один из вариантов определения: «способность (объекта, — читай процесса) функционировать как и когда требуется», т. е. как способность процесса — выполняться («главное процесс») и выполняться с успешным результатом («главное результат»).
Важно сделать два уточнения [Depend1]:
речь идет о режиме использования устройства \ процесса по назначению (освещать темный подъезд — электрическая лампочка, а не яркий монитор ЭВМ), т. е. те режимы, которые определены в ТУ (технические условия) на изделие \ процесс, включая «нештатные» сценарии, но формализованные в рамках процесса;
«потребителя, пользователя, заказчика интересует только конечный результат, вне зависимости от причин, по которым он может быть не достигнут (где „собственная“ надежность объекта является только одной из них), такая интерпретация МС (международным стандартом 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] и «Надежность в технике»:
Business continuity management vs Business Process Continuity vs Dependability in technics)
Под такую «Механику процессов» (инженерия процессов — как инструмент / framework корпоративных архитекторов) в части количественной оценки надежности бизнес‑процессов можно составить что‑то типа «Справочник по расчету надежности бизнес‑процессов». Варианты названий разные: «Надежность процессов и операций», «Операционная надежность», «Непрерывность бизнес‑процессов» (Business Process Continuity, BPC), «Процессный BCM» (инженерный BCM) и иной Mgmt (хотя слово «management» \ «управление» в названиях чего‑либо мне не нравится).
В «Надежность в процессах» входит надёжностная (вероятностная) оценка уровня безопасности и защищенности от внешних воздействий на процесс (атаки, аварии и катастрофы), оценка человеческого фактора.
Ниже домена «Надежность в процессах» расположен этаж — "домен систем" — автоматизированных и неавтоматизированных (технические и механические средства, здания, рабочие места) и их компонент. При расчетах надежности они играют ключевую роль и при этом обеспечивая в домен «Надежность в процессах» «транзит» надежностных характеристик оборудования (ПО) из домена «Надежность в технике» [27.002]. Для примера отказоустойчивый кластер (Fault Tolerant Cluster) — это область «Надежность в технике» - и это базис для построения высоконадёжных процессов.
Еще есть домен (этаж) «информация» с областью «надежность информации» (отдельная тема).
Такое размежевание (отсечение «всеобъемлющего BCM» и «Надежность в ИТ‑системах») — из заповеди \ эпиграфа к статье подчеркивает, что целостную картину обеспечения непрерывности бизнеса \ процессов \ систем можно рассмотреть через призму, образованную изоляцией домена BCM и характеристик надёжности оборудования и ПО через их контейнеры (агрегированные и локализованные сущности домена) с выделением промежуточного домена BPC.
Рассмотрим различие отказа ИТ‑системы и процесса на примере инцидента и RTO (Recovery Time Objective, целевое время восстановления) ИТ‑системы \ процесса.
Клиент приходит в офис банка чтобы положить деньги на счет (расчетный или депозит) или осуществить перевод средств, внесенных наличкой. В это время ломается автоматизированная система банка (АБС). С позиции ИТ‑системы банка, произошел инцидент «отказ АБС» и все айтишники бросились чинить АБС и пытаться уложиться в RTO. С точки зрения процесса клиентского обслуживания отказа не было (была лишь деградация сервиса): деньги принимаются, выдаются приходники, поручения клиента складываются в стопку, а отражение поступивших средств на счете будет проведено после починки АБС. С переводом средств времени у банка может оказаться еще больше, т.к. условия банковского обслуживания иногда предусматривают фразу: «Не позднее следующего операционного дня». Таким образом, на уровне «процессов» (Надежность в процессах) в части указанной номенклатура процессов — отказа вообще не было (все условия договора банковского обслуживания выполнены), в то время как на уровне «систем» (Надежность в технике) произошел критический отказ, т.к. остановилось «сердце» банка.
В данном случае был приведен пример временнОго резервирования процесса. Другие примеры временнОго резервирования в процессах — это контрольные процедуры, повторный ввод и сравнение результатов.
Иногда подобное декларируется как: клиенту не нужно видеть (знать) «подноготную» процесса, ему важен только результат процесса.
Рассмотрим «Надежность в процессах» на примере структурного резервирования в процессах. Допустим нужно оплатить процент по кредиту. При попытке войти на сайт через домашний компьютер был обнаружен обрыв кабеля к провайдеру («последняя миля»). Попытка войти через мобильное приложение также не увенчалось успехом, например, из‑за необходимости обновления приложения, а само приложение было удалено из соответствующего store из‑за санкций. В итоге, берем чемодан с деньгами и идем в ближайший банк.
Пример показывает резервирование двух автоматизированных процессов неавтоматизированным (в целом троирование), т. е. в конечном случае задача была выполнена, т.к. деньги оказались в банке ("трехлитровой", #humor).
Изоляция слоев обеспечения непрерывности (надежности) проводится через создание контейнеров для каждого слоя по типу вложенной матрешки (как и в OSI layer, Open Systems Interconnection). Примером размежевания «Надежность в процессах» и «Надежность в технике» может быть "матрешка - пирамида" из процесса и его обеспечивающих ИТ‑компонент, например, через моделирование сквозной цепочки компонент: Бизнес-процесс (подпроцесс) — Прикладная система (автоматизированная система) — Инфраструктурные компоненты (ОС, СУБД, VM, network и т.п.).
Configuration Management Database, CMDB (ITSM \ ITIL управления сервисными активами и конфигурациями) отражает «пирамиду» от бизнес-процессов до нижних инфраструктурных компонентов:
Вот они, основные уровни, самые большие квадраты, которыми можно описать всё взаимодействие бизнеса и ИТ:
Уровень автоматизированных бизнес-процессов \ уровень автоматизированных систем \ Уровень компонентов приложения \ Уровень инфраструктурных компонентов
Сверху у нас бизнес‑процесс. То, что делает существование организации осмысленным и позволяет производить прибавочную стоимость. Внизу у нас болты и гайки. Посередине — прикладное программное обеспечение и базы данных.
Вот тоже самое, но детальнее, во всей своей внутренней красоте.
Даже когда в финансовой компании нет реализованной (формализованной) CMDB (не внедрен процесс управления конфигурациями) подобную пирамиду регулятор (ЦБ) обязывает строить "руками", например, при формировании обязательной отчетной формы "0409072" — отчет по операционной надежности из 6406-У (для финансовых кредитных и не кредитных организаций). Наиболее ценное в форме — это набор длинных и непонятных строчек, содержащих смысл, показанный на рис. 2.1 (немного поправлено из [TAB24]).
Сложной для понимания строкой (можно было сделать понятнее, человеко‑читаемо) в форме "0409072" кодируется (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), так и причудливую строку для формы "0409072". Общий механизм реализации показан в [SmartDesign24], т.к. генерация схемы из таблицы через промежуточный dot \ graphviz. Таким образом, будет практическая польза для BPM\ EA от GRC («Управление рисками в соответствии с требованиями регулирующих органов») 787П / 779П / 6406-У — раз финансовым организациям все равно собирать и сдавать "0409072" форму, то можно одновременно с минимальными затратами предоставить корпоративным архитекторам (Enterprise Architecture) инструмент визуализации архитектуры прямо с привязкой к бизнес‑процессам компании.
Не только CMDB
Когда мы говорим про классическую CMDB и её пирамиду «от верхних бизнес-процессов до нижних инфраструктурных компонент», то не упоминаем про возможность построения \ резервирования бизнес-процесса его неавтоматизированной реализацией (см. пример "оплатить процент по кредиту"). Поэтому строго говоря «процессный полный CMDB» должен содержать и неавтоматизированную компоненту.
Кроме того, иногда автоматизированные процессы наоборот являются резервными по отношению к "ручным". Например, наиболее критический «ручной» процесс КСБУ стратегического звена управления резервируется полностью автоматическим процессом (коэффициент автоматизации = 1) под названием «Мертвая рука».
2.2 Состав процесса
Определим «Процесс» как функцию с аргументами:
входящее обеспечение (вход) — входные элементы, включая материалы, заготовки, внешние сервисы;
ресурсное обеспечение, включая человеческий ресурс (рабочая сила) в виде исполнителя процесса и его инструментарий: механизмы, средства автоматизации, рабочие места.
Для упрощения будем считать, что сама функция задается только алгоритмическим обеспечением, выраженным через workflow & docflow. Функцию с аргументами см. рис. 2.2:
В таблицах рис. 2.2 обыгрывается эталон качества, выраженный в девятках. Таблица слева это коэффициент готовности (показатель класса BPC, Business Process Continuity) — как вероятность застать систему (процесс) в работоспособном состоянии: как хорошо процесс работает, без учета его результата (его результативности). Например, «пять девяток непрерывности» (готовности) составляет простой в 5,25 минут в год (525 600 минут), что равноценно 10 минутам простоя на один миллион минут (чуть менее двух лет). Сравните этот же показатель с «числом сигм» («six sigma», Motorola, LSS), определяющий качество изделий, продукции, результата процесса, из правой таблицы рис. 2.2: те же «пять девяток», но уже качества — результативности.
3. Результативность процесса
Надежность в процессах во многом повторяет «Надежность в технике», но реализуется на более верхнем домене (уровне) и привносит специфику, например, с одной стороны сложно говорить о показателях хранения и транспортабельности процесса (свойство сохраняемости [27.002]), а с другой можно говорить о свойстве "тиражируемость процесса", но это уже скорее про технологичность, а не про надежность.
Как было показано выше надежность процесса характеризуется двумя «зонами определения»: готовностью исполнять экземпляр процесса (готовность к работе, исполнению задачи) и качество — результат процесса (результативность процесса). Остановимся подробнее на последнем.
Результативность — это параметры «полезного» выхода процесса:
а) качественно, т.е. не хуже предельного значения, характеризующего качество продукта и
б) в срок, например, при превышении обещанного клиенту срока рассмотрения заявки (кредита) может быть уже не важно были ли работоспособны процессы этого рассмотрения (готовность процесса) и сам результат рассмотрения (пункт а), т.к. клиент уйдет к другому поставщику услуг.
Оценку результативности процесса удобно проводить методами статистического анализа. Результативность измеряют разнообразными величинами:% годных и сквозной выход годных, дефектов на единицу (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. Вопросы
Дайте ссылку, если что‑то подобное обсуждалось, т. е. «скрещивание» BPM и теории надежности, выделение понятия «Надежность процессов» и систематизация подходов.
Поделитесь примерами обязательных для финансовых компаний документов, закрывающих (или раскрывающих) реализацию требований 787П / 779П, что‑то типа «Политика обеспечения Операционной надежности» (обезличка, шаблоны, «рыба» и т. п.).
Посоветуйте форумы \ ТГ‑каналы (желательно не вендорные), где идет обсуждение ruGRC №.787/779П и т.п.
Есть ли ИИ модель, до обученная СТО БР хххх, ГОСТ Р 57 580.3–2022 — ГОСТ Р 57 580.4–2022 и 719П / 787П / 779П и т. п.?
Что из западного Best Practice наиболее близко и подробно описывает (напоминает) серию ГОСТ: Р 57 580.1/2/3/4
Имеется ввиду не разнообразные общие концепции «всеобъемлющего» BCM (BS 25 999, ISO и т. п.), а откуда этот конкретный «копи‑паст» (фрагменты текста) или все же аналогов нет?
Вместо заключения. Выше показан общий подход, концепция «Надежность в процессах» с примерами. Также не встречал ранее сопоставления «пять девяток непрерывности» (готовность системы, простой в 5,25 минут в год) с «числом сигм» («six sigma», Motorola, LSS), по сути «пять девяток качества». В целом, это про количественное выражение «главное процесс» (простой в минутах) vs «главное результат» (качество в сигмах).
В следующий раз надеемся увидеть показатели «надежности процесса» класса «Business Process Continuity» и их расчет.
Некоторые ссылки
[BPM23] В толковый словарь Business Process Management: Бизнес-функция vs Бизнес-процесс
[SmartDesign24] ВРМ. Смарт-инструменты «Таблица -> Схема» для формализации бизнес-процессов. Рестайлинг ARIS SmartDesign
[27.002] ГОСТ 27.002—89 Надежность в технике. Основные понятия. Термины и определения
[27.003] ГОСТ 27.003—90 Состав и общие правила задания требований по надежности
[BCOR23] Business continuity & Operational resilience: вчера, сегодня, завтра. Откуда пришло и что дальше?
[Ушаков66] И. Ушаков, Б. Козлов «Справочник по расчету надежности» 1966
[Морф23] Морфология современного русского языка: основы теории, упражнения, задания. Т.Е. Никольская и др.
пункт 1.1.2. Относительные прилагательные (стр. 71):
Возможна синонимия со словосочетаниями ‘сущ. + сущ.’, в том числе с предложно-падежными конструкциями (институтская библиотека – библиотека института, горный климат – климат в горах).
[Depend1] В. Нетес и др. Как нам определить, что такое «надежность»
[Depend2] С. Алпеев, Терминология надежности
[Depend3] Л. Александровская и др. Современные методы обеспечения безотказности сложных технических систем
[sapland] Примерный расчет степени готовности системы
Степень готовности системы описывается через коэффициент готовности, при этом он является безразмерной величиной и не может быть больше 1
[ISO9000] ИСО 9000-1-94
ГОСТ 27.015-2019 (МЭК 60300-3-15: 2009) Управление надежностью. Руководство по проектированию надежности систем
ИСО 9000 Системы менеджмента качества — Основные положения и словарь. Неофициальный перевод «Русский Регистр»
ГОСТ Р ИСО 9000-2015 (html)
[sigma] Sigma-Level-Table (Six Sigma Online Certification)
https://www.sixsigmaonline.org/Flash_Videos/Supplemental/Printable/Guides/Sigma-Level-Table.xls
Основы 6 сигм:
https://www.lean-consult.ru/blog/kak-rasschitat-uroven-sigma-processa-v-metodologii-6-sigm/
https://www.six-sigma-material.com/Protected-Pages.html
https://westgard.com/resources/29-resources/416-sixsigtable.html
https://www.isixsigma.com/sigma-level/yield-to-sigma-conversion-table/
https://sixsigma.ru/glossary_term/yield/
[EasyEA23] Простая Enterprise Architecture. Архитектура компании садоводов
[TAB24] 16.07.2024. Вебинар. Отчет по операционной надежности Ответы на вопросы. Технологии. Автоматизация. Бизнес.
Basel: https://www.bis.org/bcbs/publ/d515.htm https://www.bis.org/bcbs/publ/d516.htm
Продолжение:
Надежность в процессах. Часть 2
PS1 Разбор комментариев
частности накиданы без особой связки. Читать тяжело.
Про Особые Связки
1 Раз речь про «Надежность в процессах и операциях», то простым языком показываем составляющие, что такое Надежность на примере «Надежность в технике» (классическая теория надёжности) и что такое Процесс, причем, в общем случае, Процесс = Операция. Таким образом «Надёжность процессов» и «Операционная надежность» – рассматриваем как синонимы (чтобы не было сказано в п. 1.4 716П).
Также показываем термин вероятность (количественная мера надежности), риск (вероятность чего-то плохого), критерий отказа – ключевых терминов «Надёжность процессов» \ «Операционной надежности». Это связка к составному термину от его элементов и к связанным с ним понятиям.
2 Показываем, что техническая основа «Надёжности процессов» взята от «Надежность в технике», а идейная от Business continuity management (BCM) – отсюда и термин Business Process Continuity.
На данный момент «место под солнцем» уже везде занято, поэтому чтобы очертить (застолбить) новую концептуальную нишу, нужно кого-то подвинуть (растолкать). На склоне пирамиды, где «разогрета» (под солнцем, как правило маркетинговым и регуляторным) BCM и уже «окаменела» теория надёжности (нет развития), мы выделяем между ними «процессный» слой, домен, «этаж» (как элемент Business Process Management, BPM) и в нем описываем концепт «Надёжность в процессах».
3 На примере (офис банка) показывается различие в подходах в Надежность в процессах и Надежность в технике. Далее поясняется метод изоляции – точнее инкапсуляции (in capsula) процессного уровня и ИТ-инфраструктуры. Чтобы сделать это более конкретным немного углубились в «Управление конфигурациями» (см. общая теория - ITSM, библиотека - ITIL, реализация - HPSM и т.п.).
Более того, некоторые кто даже не внедрял «Управление конфигурациями» обязан все равно делать привязку верхнеуровневых бизнес-процессов к «болтам и гайкам из подполья» ИТ-инфраструктуру (нижнеуровневая инфраструктура), так как их обязывает в этом регулятор, например, финансовые компании. Это про совсем практическое применение Операционной надежности, т.к. регулярную отчетную форму «0409072 Сведения о показателях операционной надежности кредитной организации и применяемых ею информационных технологиях …» уже нужно сдавать, а срок внедрения ГОСТ Р 57580.3/4-2022 c названием «Ensuring operational resilience» (см. рис. 4.1) – конец следующего года (для ряда компаний).
Таким образом показана связка предлагаемой теории к практическим и суровым требованиям регулятора. При этом регулятор (ЦБ) и стандартизатор ГосСтандарт (прежнее название) не удосужились описать саму концепцию Операционной надежности и никуда не отсылают. ГОСТ вроде как «аналогов нет» и положения, указания и методики ЦБ тоже никуда "на запад" не отсылают.
С одной стороны, есть практическая актуальность, вызванная жесткими требованиями регулятора, с другой - «идеологическая пустыня» (точнее "диверсия", см. «Методологические вводные», включая ссылку на 716П) - вследствие отсутствия идейного / концептуального наполнения требуемой регулятором «Операционной надежности».
4 Ключевой момент – это рассмотрение элементов процесса – как ресурсное обеспечение и вывод формулы через элементы обеспечений (п. 2.2 Состав процесса):
function (input, hr, tool) = Y.
Рисунком и формулой подчеркивается мысль, что «Операционной надежность» \ «Надежность процессов» - это скорее «стержень» от BPM (с математизацией структуры абстракции «процесс») с "насаженным" на него BCM, теорией надежности и ИТ-инфраструктурой (CMDB).
Там же (п. 2.2) обыграны «пять девяток» готовности процесса («Главное процесс») и качества из six sigma («Главное результат»).
В этом параграфе упор сделан на подробную картинку, поэтому текста мало, а правую часть рисунка раскрывает следующий раздел «Результативность процесса» (это тоже связка, раскрытие части приведенного выше рисунка).
Вопросы к заключению:
При сравнении критериев по времени производства пригодности произведенного продукта, необходимо учитывать еще то, что некачественный продукт отнимает больше времени, чем производится (обработка рекламации, возврат, замена). Поэтому так напрямую сравнивать нельзя.
Если имеется ввиду «При сравнении критериев по времени производства И пригодности произведенного продукта» в контексте величин «девяток» (про них в «Вместо заключения»), то время производства продукта в общем случае не связано с характеристикой простоя (готовность в «пять девяток»).
В начале уже есть фраза "текст будет обнадежен от типовых угроз " - при первом и втором прочтении я так и не понял почему используется слово "обнадежен".
Лететь – ОбЛететь, вязать – ОбВязать, варить - ОбВарить, везти – ОбВезти, венчаться – ОбВенчаться и т.п.
«ОбНадежить» - образовано «об» и «надежность» – и как итог «сделать надёжным» ("вселить надёжность", повысить вероятность хорошего события - т.е. усилить надежу), в контексте указанных методологических вводных – это снизить риски чрезмерного усложнения, терминологической путаницы, неправильной декомпозиции и других типовых угроз.
БезНадёжный (без надежды), безНадёжно (кстати бывает и "без надежно"). В целом: Надёжность и Надежда - как вероятность чего-то хорошего в противовес риск - вероятность чего то плохого.
