КАРТИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ И ПОСТРОЕНИЕ ДИАГРАММ ПОТОКОВ ДАННЫХ: ОТ «НАСКАЛЬНОЙ ЖИВОПИСИ» К МОЩНОМУ ИНСТРУМЕНТУ

По мере того, как в нашу повседневность все чаще врывается словосочетание «критическое мышление», интуитивно возникает ощущение, что проявить его можно в том числе с использованием средств автоматизации. Ведь к чему сводится системный подход в этом отношении? К двум последовательным шагам [1][2]:
1. Картированию бизнес-процессов;
2. Построению диаграмм потоков данных.
Ведь без такого визуального представления проводить оценку сложных сценарных систем (и реализуемых ими функций) в фармацевтической отрасли – это сродни попытке разобраться на пальцах в московском или пекинском метрополитенах без вагонной схемы линий метро. Впрочем, в 21-м веке эти же схемы линий ме-тро являются интерактивными, и пассажиры предпочитают пользоваться ими со своих смартфонов. В то же время примеры по картированию и построению диаграмм в фармацевтической промышленности по-прежнему выполнены, условно говоря, в MS Visio, в режиме «наскальной живописи», крайне редко используя со-временные средства и нотации моделирования бизнес-процессов, такие как EPC (event-driven process chain), BPMN 2.0 (business-process model and notation) и т.п.

---

По мере того, как в нашу повседневность все чаще врывается словосочетание «критическое мышление», интуитивно возникает ощущение, что проявить его можно в том числе с использованием средств автоматизации. Ведь к чему сводится системный подход в этом отношении? К двум последовательным шагам [1][2]:

1. Картированию бизнес-процессов;
2. Построению диаграмм потоков данных.

Ведь без такого визуального представления проводить оценку сложных сценарных систем (и реализуемых ими функций) в фармацевтической отрасли – это сродни попытке разобраться на пальцах в московском или пекинском метрополитенах без вагонной схемы линий метро. Впрочем, в 21-м веке эти же схемы линий метро являются интерактивными, и пассажиры предпочитают пользоваться ими со своих смартфонов. В то же время примеры по картированию и построению диаграмм в фармацевтической промышленности по-прежнему выполнены, условно говоря, в MS Visio, в режиме «наскальной живописи», крайне редко используя современные средства и нотации моделирования бизнес-процессов, такие как EPC (event-driven process chain), BPMN 2.0 (business-process model and notation) и т.п.

В стремлении соответствовать регуляторным требованиям в отношении целостности данных, фармацевтические компании вынуждены искать и/или разрабатывать самостоятельно неспонтанные подходы. Ведь просто медитировать на таблицу 1.1. [2] с перечнем ALCOA+ (в настоящий момент уже ALCOA++ – добавился параметр Traceable [4]) недостаточно. От этого само по себе не возникнет отчетливое представление о взаимосвязи данных с бизнес-процессами, а безотносительно бизнес-процессов весьма трудно сделать заключение о соблюдении принципов целостности данных. Ведь непонятно, где эти данные генерируются, как обрабатываются, где используются, как сохраняются, архивируются и, возможно, уничтожаются. Эти события не происходят в вакууме, а связаны с осуществляемыми бизнес-процессами. Если мы, к примеру, хотим сделать оценку соблюдения принципа «последовательность» (consistent), то, опираясь на пояснения (data expectation) к упомянутой таблице 1.1 [2], мы рассчитываем увидеть отметки времени и даты в ожидаемом порядке. В ряде случаев этот порядок интуитивно понятен, но зачастую без четко определенной последовательности шагов не очевидно соответствие этому принципу.

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

Другой пример не столь очевиден. Заполнение данных при проведении квалификации оборудования того же производства твердых лекарственных форм, например ламинарного укрытия для взвешивания. Одним из таких испытаний будет визуализация воздушных потоков, доказывающая, что соблюдаются условия однонаправленности в зонах работы с открытым продуктом при взвешивании, реализуются физические и организационные мероприятия по предотвращению перекрестной контаминации согласно п. 5.21 [5]. Протокол квалификации содержит, как правило, специальный утвержденный бланк, где описан рабочий метод, критерии приемлемости, используемое оборудование, технические средства и т.п. Видеосъемка таковой визуализации происходит в одну дату и временной интервал. Но просмотр, итоговый монтаж видео (часто с добавлением субтитров или комбинированием ракурсов) осуществляется в более поздний временной момент. И тут будет сразу ряд вопросов. Какую дату внести в утвержденный бланк испытаний, который будет входить в состав итогового отчета? Дату проведения самого испытания с генерацией тестового аэрозоля и видеофиксацией первичных данных? Дату формирования итогового видео? Когда и кем было сделано заключение о соблюдении критериев приемлемости в части однонаправленности воздушного потока? Самими исполнителями испытаний? Компетентным кворумом? На основании первичных данных? Или на основании итогового смонтированного видеофайла? При монтаже видеофайла – что происходит с первичными видеофайлами? Сохраняются ли они в неизменном виде? Уничтожаются ли после монтажа и принятия решения о соответствии критериям приемлемости на основании итогового видеофайла (-ов)?

Вроде бы простое испытание, очевидные вопросы, но без четко определенного бизнес-процесса и установленного порядка регистрации данных, их преобразования, оценки, хранения выбранных данных и архивирования/уничтожения оригинальных данных сделать вывод о соблюдении принципа «последовательность» затруднительно.

Попробуем на таком относительно простом примере применить принципы ALCOA++ на практике.

Данные – это факты, изображения и статистика, собранные воедино для ссылок или анализа. Все первичные записи (original records) и истинные копии (true copies), включая исходные данные (source data) и метаданные, а также все соответствующие преобразования и отчеты с задействованием этих данных, которые генерируются или записываются во время GxP-деятельности и позволяют целиком и полностью воспроизвести, и оценить GxP-деятельность (6.1, [3]). Целостность данных – это степень, в которой данные полны (complete), последовательны (consistent), точны (accurate), достоверны (trustworthy), надежны (reliable), и эти характеристики данных поддерживаются в ходе их жизненного цикла. Данные должны накапливаться и сохраняться безопасным способом, с обеспечением их прослеживаемости (attributable), читаемости (legible), своевременности записи (contemporaneously recorded), подлинности (original) или создания истинной копии (true copy) и точности (accurate). Обеспечение целостности данных требует соответствующие системы качества и управления рисками, включая приверженность здравому смыслу и надлежащим практикам документирования (6.1, [3]).

АНАЛИЗ ИМЕЮЩИХСЯ ПОДХОДОВ

На помощь могут прийти простейшие определения – что такое данные и что такое целостность данных [3].

Также важным будет применение критического мышления. В п. 20.3.2 Приложения М12 «Критическое мышление»

[1] сформулировано, что без полного понимания потоков данных не может быть достигнуто соответствие принципам целостности данных. Причина проста – вы просто не знаете ваших процессов. Не вы ими владеете, а они владеют вами. В этом же параграфе дана ссылка на руководство ISPE по целостности данных [2], где стоит выделить Приложение D2 «Картирование процессов и интерфейсов».

В п. 14.1 упомянутого Приложения D2 [2] сразу же указываются два инструмента:

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

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

С другой стороны, это не является чем-то инновационным, и даже в методологии SADT, известной с 1960-х, с последующей трансформацией в нотации IDEFx [6], это было реализовано как принцип иерархического доминирования и структурной декомпозиции.

В более современной нотации BPMN [7] также могут использоваться подпроцессы и вызовы (call-activity) для этой же цели.

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

С другого фланга к использованию формальных нотаций нас может простимулировать руководство MHRA [3] с упоминанием в п. 3.4 DIRA (data integrity risk assessment) – необходимости оценки рисков целостности данных:

«Примером приемлемого подхода является проведение оценки рисков целостности данных (DIRA), где процессы, генерирующие данные или в которые данные поступают, картируются, и все форматы и их средства управления идентифицируются, а критичность данных и связанные с ними риски документируются».

Чертежи фармацевтических предприятий не запрещено выполнить на кульмане от руки и в настоящий период, просто в эпоху AutoCAD и производных систем и/или аналогов (САПР) все труднее найти «призраки прошлого» с карандашами разной степени твердости и мягкости, проверяющих свои расчеты на логарифмической линейке. Вот и при моделировании бизнес-процессов 21-й век предоставляет инструментарий гораздо богаче, чем просто графические редакторы.

В чем ключевые недостатки неформализованных блок-схем, приведенных в качестве примеров в Приложении D2 [2], при том, что в целом они допускаются? Таких недостатков можно выделить два:

1. Любые подобные схемы нуждаются в развернутом текстовом и/или табличном описании, и таковое описание выполняется вручную;
2. Любые подобные схемы могут содержать логические ошибки при построении (особенно если предполагаются элементы логического ветвления), которые сложно выявить по тексту до момента реализации на практике и/или в программном коде.

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

ВОЗМОЖНЫЕ РЕШЕНИЯ ПО АВТОМАТИЗАЦИИ

Для детализированного примера остановимся на нотации BPMN 2.0 [7], несмотря на то, что уже выше упоминали и IDEFx, и EPC, и, разумеется, существует еще множество нотаций и методологий, равно как и программных продуктов, поддерживающих все упомянутые инструменты.

В чем преимущество нотации BPMN 2.0? Она достаточно широко распространена, в первом приближении достаточно легко читается как специалистами, так и пользователями с минимальным погружением в ее правила. Для нее создано большое количество поддерживающего программного обеспечения, в т.ч. облачных инструментов, реализующих совместную работу. И, что самое главное, BPMN 2.0 позволяет строить как аналитические модели (т.е., грубо говоря, для презентации, просмотра или создания последующей документации на их основе), так и исполняемые модели (по существу, реализуя концепт low-code/no-code). И последнюю историю на определенном этапе стали поддерживать SAP, Oracle, наверное, в немалой степени поспособствовав росту популярности BPMN 2.0 в т.ч.

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

Но обо всем по порядку. В целом квалификационная деятельность может быть представлена в общем виде на рис. 1. В отдельный пул (Qualification activity) выделены начальное событие (Qualification activity start) и цепочка последовательных верхнеуровневых шагов – создание и утверждение протокола (Protocol creation and approval), выполнение испытаний (Test execution), создание и утверждение отчета (Report creation and approval). Завершается все конечным событием (Qualification activity end) в рамках этого же единственного пула.

На данном верхнем уровне нет необходимости разбиения пула на отдельные дорожки. Но на примере шага выполнения испытаний (Test execution) показано в виде т.н. функции вызова (call activity), что предусмотрена дальнейшая детализация. Это означает, что шаг выполнения испытаний декомпозирован на отдельной схеме, представленной на рис. 2.

При декомпозиции шага выполнения испытаний (рис. 2) уже единым пулом становится он сам (Test execution), а также появляется необходимость в создании дорожек, соответствующих ролям (Validator 1, Validator 2, Approval team).

В принципе, различные системы BPMS (business-process modeling system) – такие как ARIS, Bisagi, strombpmn etc. – представляют различный инструментарий и в ряде случаев не рекомендуют использовать дорожки, отображая и роли, и другие элементы (например, документы) за счет реализации различных слоев модели. Но классическое описание нотации BPMN 2.0 все-таки выделяет дорожки, поэтому и в рассматриваемом примере мы пойдем по классическому варианту построения модели.

Целью данной статьи не является обзор нотации BPMN 2.0 и конкретных систем BPMS, тем не менее несколько вводных по модели, представленной на рис. 2 следует сделать для лучшего ее понимания. Любая из схем всегда должна начинаться со стартового события (отображается в форме круга с обычным контуром) и завершается конечным событием (отображается в форме круга с утолщенным контуром). Шлюзы (элементы логического ветвления, привычные нам по неформализованным блок-схемам и/или алгоритмам «ромбики») могут иметь различное обозначение, на рис. 2 использовано только два вида шлюзов – эксклюзивный и параллельный.

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

Но при построении исполняемой модели ее должна правильно «прочитать» машина, а машина – достаточно «плохой читатель», поэтому необходима математическая точность.

Тут уже важна конкретная BPMS-система, поэтому назовем ее – в рассматриваемом примере использована система stormbpmn [8]. Разумеется, другие системы имеют в целом аналогичный функционал, различающийся в деталях и конкретных наборах функций.

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

Шлюз эксклюзивный (соответствует логическому «ИЛИ»)

Шлюз параллельный (соответствует логическому «И»)

Мы видим, что при запуске на исполнение модели сформированный в начальном событии токен направляется сразу же на закрывающий эксклюзивный шлюз. Пока пропустим этот момент на том основании, что шлюз закрывающий, и перейдем к следующему шлюзу – открывающему параллельному, т.е. в результате его прохождения реализуется логическое «И», что означает формирование двух токенов, которые идут по параллельным веткам. В рассматриваемом примере это и физическое выполнение генерации тестового аэрозоля (fog generation in clean areas) согласно описанному в протоколе квалификации рабочему методу со стороны первого валидатора (Validator 1), и видеосъемка, осуществляемая вторым валидатором (Validator 2), результатом которой является накопление первичных данных (raw data) – эти события действительно происходят параллельно. По правилам нотации BPMN 2.0, раз мы получили два параллельных потока информации (что визуализируется движениями двух токенов), то далее, если выполнение модели не приводит к двум различным итогам, а есть еще последовательное выполнение дальнейших шагов, следует снова объединить потоки информации в один за счет закрывающего шлюза того же типа, что и открывающий, т.е. параллельного (см. рис. 3).

На рис. 3 сделана мгновенная фотография при движении токенов, иллюстрирующая как раз момент выполнения своих активностей первым и вторым валидатором (Validator 1, Validator 2) и перед объединением токенов в один поток перед активностью кворума согласователей (Approval team) в части оценки исходных видеозаписей и их утверждения (Raw video files estimation and approval). При этом на выходе такой активности возможно два итога:

1. Утверждение выполненного испытания на основании таковой оценки исходных видеофайлов (Approved).
2. Неутверждение выполненного испытания на основании таковой оценки исходных видеофайлов (Not approved).

Для реализации этих двух возможных итогов в модели применен эксклюзивный шлюз, т.е. тот, который реализует логическое «ИЛИ» с осуществлением только одного итога. При этом видим, что в выбранный момент времени один из исходов (Not approved) выделен как активный, а второй (Approved) – как неактивный (показан серым цветом). Это значит, что шлюз переключен на итог 2 – неутверждение, и объединенный токен пойдет на повторный круг через упомянутый в самом начале закрывающий эксклюзивный шлюз. Без последнего шлюза невозможно корректно вернуть токен на повторный круг. Если исключить в модели этот закрывающий эксклюзивный шлюз, то, начав симуляцию (проигрывание модели), токен «упрется» в открывающий параллельный шлюз. Исходя из функционального назначения этого шлюза (параллельный), стартовый токен «застынет» в этой точке в вечном ожидании второго токена, источником которого может стать только последующий эксклюзивный шлюз, до которого процесс просто «не добежал». Т.е. модель застопорится в логической ошибке, которую простой человеческий глаз может и не распознать.

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

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

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

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

На рис. 4 показано, что для функционального блока доступны опции, из которых детализирована опция внешних настроек. На примере сервиса strombpmn это вкладки «Главная» (Main), «Описание» (Description), «Комментарии» (Comments). Не сваливаясь в описание по работе с конкретной BPMS, укажем только, что как вариант к функциональному блоку могут быть назначены исполнители (Assignee) и элементы архитектуры (Elements of architecture). Как и было описано выше, возможность добавления исполнителей в качестве отдельно отображаемого слоя может избавить от необходимости использования дорожек, а примером элементов архитектуры могут быть используемые (или генерируемые) документы.

Выполненное описание по каждому функциональному блоку в дальнейшем может быть использовано для создания общей непротиворечивой спецификации, в том числе и в автоматическом режиме. В идеале, так лучше сформировать изначальную URS (user requirements specification – спецификацию требований пользователя). Но в целом не проблема, если подобная модель и ее описательная часть возникнут на этапе разработки FS (functional specification – функциональной спецификации), как «зеркала» URS.

Возвращаясь к примеру на рис. 2, следует отметить, что, имея видео симуляции исполняемой модели executable model video simulation, нет необходимости детально останавливаться на выполнении каждого шага и логических веток. Видео гораздо более наглядно, чем статический рисунок.

Тем не менее, сделаем обобщение в виде тезисов:

1. После утверждения кворумом согласователей (Raw video files estimation and approval) – когда реализуется вышеописанный итог 1 первого эксклюзивного шлюза (Approved) – токен попадает на следующий параллельный шлюз, формируя два параллельных потока:
2. Обработка полученных данных (время видео 0:40):

2.1 Записи в бумажной форме протокола результатов

(Records in paper-based filling form)

2.2 Обработка видео (Video-editing)

3. После выполнения шагов 2.1 и 2.2 токены снова объединяются в один через закрывающий параллельный шлюз, и следующим шагом является формирование отчета (Report creation) (время видео 0:45).
4. Далее идет оценка уже готового отчета о квалификации и его утверждение (Report estimation and approval). И тут тоже возможны два итога, реализованные через открывающий эксклюзивный шлюз:

4.1 Утверждение (Approved) – далее идет конечное событие – исполнение модели завершается.

4.2 Неутверждение (Not approved) – который, в свою очередь, также формирует два итога:

4.2.1 Коррективы нужно внести в обработку видеофайлов. При этом, очевидно, нужно будет сформировать как новый итоговый видеофайл, так и повторно заполнить новую редакцию бумажного заполняемого бланка (как минимум в части ссылки на вновь созданный итоговый видеофайл с обновленной временной отметкой) (время видео 0:50).

4.2.2 Коррективы нужно внести только в сформированный отчет о квалификации (ссылка с привязкой ко времени тут лучше (время видео 1:00).

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

Это означает, что номинально, по неформализованным блок-схемам, такие ошибки можно пропустить или не придать им существенного значения. Но тогда и о соблюдении принципов целостности данных можно судить лишь «приблизительно», сделав вывод только о «позитивном намерении» их соблюдать, но не более того. Например, если вести речь о принципах своевременности (contemporaneous) или последовательности (consistent). Для бумажных протоколов и отчетов о квалификации это даже может не вскрыться при проектировании процесса, что, однако, впоследствии может стать «сюрпризом» на инспекционных аудитах. Например, идя выше по итогу 4.2.1, видеофайл корректируется, а сопровождающая его запись в бумажном заполняемом бланке – нет. Стало быть, эта бумажная запись может при таком исходе быть датированной ранее, чем итоговый видеофайл. Хотя при общем позитивном итоге испытания не факт, что этот аспект контрастно бросится в глаза. А вот для электронных систем (предположим, записи вносятся не в бумажный заполняемый бланк, а в веб-форму) такие ошибки на выходе дадут неработоспособную систему, исправление которой будет дольше и дороже без такого моделирования. Например, видеофайл изменен, но его нельзя добавить к заполняемой веб-форме на втором и последующих кругах согласования или нельзя изменить саму веб-форму после первого круга согласования.

Упомянем еще один аспект, затронутый в самом начале статьи относительно предложенного примера, но не раскрытого в модели. Что происходит с исходными данными – исходными видеофайлами, на основании которых осуществляется итоговый монтаж? Стоит ли их сохранять где-то отдельно или же прикладывать точно так же к отчету о квалификации? Можно и развить тему – если выводы о соблюдении критериев приемлемости делает команда согласователей (Approval team) на этапе оценки исходных видеозаписей (Raw video files estimation and approval), то для чего затем в случае реализации повторного согласования с итогом 4.2.1 корректировать не только обработанное видео (где действительно могут быть поправлены титры или формат склейки кадров), но и записи в бумажном заполняемом бланке? Такие записи могли появиться в момент выполнения теста с соответствующим заключением, подтвержденным компетентным кворумом (Raw video files estimation and approval), со ссылкой на будущее приложение с итоговым видеофайлом. Как вариант – это также допустимо. Тогда и модель должна будет претерпеть некоторые изменения. Разумеется, что существует не один способ соблюдения принципов целостности данных.

В любом случае, для ответов на эти вопросы, разумеется, приведенная модель должна быть детализирована. Это не обязательно декомпозиция на уровни ниже (как это реализовано при переходе от рис. 1 к рис. 2), достаточным может оказаться добавление описания в соответствующей вкладке и/или добавление элементов архитектуры (см. рис. 4).

Но опишем на словах, что если создание обработанного видеофайла рассматривать как создание истинной копии (true copy), то тогда действительно после его письменного подтверждения (в рамках шагов 2.1 и, опционально, 4.2.1) и утверждения отчета о квалификации в целом (выполнение шага 4.1) исходные видеофайлы можно уничтожить. Конечно, допустим вариант и их полного сохранения, но в ряде случаев этот массив данных может превышать терабайты. Реальная конфигурация процесса должна быть обоснована оценкой рисков и отражена в модели. Например, удаление исходных видеофайлов какой-нибудь десяток лет назад было бы вполне логичным шагом – такие исходные видеофайлы и читаются слабо без сопровождающих их комментариев, и в целом вариантов сфабриковать видео при обработке было не так уж и много. Риск сфабриковать чек со счетчика частиц при классификации чистых помещений намного выше. Тем не менее, никто не требует видеофиксации, что счетчик частиц установлен именно в классифицируемом помещении и именно в нужной точке. Более того, раз уж мы коснулись чеков при измерении счетной концентрации частиц, то их ксерокопия при оформлении отчетов о квалификации как раз и есть пример создания истинных копий (true copy), поскольку сами оригиналы чеков со временем выцветают. Следует отметить, что на примере бумажных чеков мы описываем хоть и легитимный, но достаточно устаревший способ формирования отчетов, поскольку не первое десятилетие могут быть использованы электронные отчеты со счетчиков частиц вместо бумажных чеков. Однако, возвращаясь к видеофайлам, в настоящее время, по мере развития искусственного интеллекта, обосновать достаточность только итогового обработанного видео может оказаться недостаточно без дополнительных мер (например, обработка исходных видеофайлов в конкретном программном обеспечении и только на конкретных рабочих компьютерах без доступа в интернет и т.п.).

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

Ведь даже последняя цепочка рассуждения говорит нам о том, что на примере модели BPMN 2.0 мы выполнили не только первый шаг, рекомендуемый ISPE [1][2] – построение карт бизнес-процессов, но и полностью охватили второй – построение диаграмм потоков данных, причем сделали это в рамках одной модели в нотации BPMN 2.0. Да, для простоты изложения мы не добавляли в рамках рис. 2 документы/ данные и/или элементы архитектуры – мы только упомянули о такой возможности, проиллюстрировав ее на рис. 4. Но очевидно, что именно на конкретную последовательность шагов логично проецируются данные с соответствующими этапами их жизненного цикла, включая создание (например, исходный видеофайл формируется в результате выполнения соответствующего функционального блока (Video-recording)), преобразование (Video-editing) и т.п. Т.е. у нас в руках интегрированный инструмент, а не разрозненные схемы. Разрозненные схемы формально имеют под собой, конечно же, одну основу, но для сложных сценарных систем могут очень быстро рассинхронизироваться между собой. В то же время модели BPMN 2.0 взаимосвязаны и, например, если вы переименуете элемент архитектуры (документ) или переназначите исполнителя в одной части модели, это же изменение применится по всем остальным частям модели. Не говоря уже о более широких возможностях как в части бизнес-аналитики (реестр всех функциональных блоков и данных, с ними связанных), так и в плане симуляции исполнения моделей задолго до их реализации в программном коде и/или физическом мире.

ЗАКЛЮЧЕНИЕ

Применение нотации моделирования бизнес-процессов BPMN 2.0 представляет собой очень мощный инструментарий для реализации соблюдения принципов целостности данных ALCOA++ в полуавтоматическом режиме, с проверкой исполняемых моделей на непротиворечивость и отсутствие логических ошибок. Проектирование бизнес-процессов с применением моделей BPMN 2.0 может быть рекомендовано как стартовый шаг проработки сложных сценарных систем еще на этапе создания URS. Это позволяет избежать ошибок на ранних этапах, что, в конечном итоге, ускорит и удешевит разработку с одновременным обеспечением регуляторного соответствия.

ИСТОЧНИКИ

1. GAMP 5 Guide 2nd Edition
2. GAMP Guide: Records & Data Integrity
3. MHRA ‘GXP’ Data Integrity Guidance and Definitions
4. https://blog.pqegroup.com/csv-data-integrity/alcoa-what-you-need-to-know
5. EudraLex – Volume 4 – Good Manufacturing Practice (GMP) guidelines
6. https://www.idef.com/idefo-function_modeling_method/
7. https://www.bpmn.org/
8. https://stormbpmn.com/

ООО «ПИКЬЮИ СИАЙЭС»

Москва, ул. Днепропетровская, д.2

Тел. +7(495) 664-46-91

Тел. +7(926) 666-85-18

Е-mail:ru.info@pqegroup.com

Реклама, ООО «ПиКьюИ СиАйЭс», Маркер: 2RanykiDNYy