Моделирование бизнес-процессов на примере требований GDP. Нотации IDEF0 & BPMN 2.0 — для чего вообще это нужно?

Долго я собирался с мыслями, стоит ли вообще затрагивать указанную тематику – чисто внешне она ведь лежит вроде как далековато от фармы. Однако, вполне возможно, что это только так кажется, и это во-первых. А во-вторых, как уже не раз было подмечено, фармацевтическая отрасль – являясь безусловно одной из самых наукоемких и ресурсоемких отраслей промышленности зачастую… катастрофически отстает от научно-технического прогресса. За примерами далеко ходить не нужно, при этом важно понимать, что такая ситуация характерна не только для наших широт, но и для отрасли в целом, в международных масштабах. Т.е. дело не в нашей какой-то сиволапости или дремучести, а в консервативности отрасли как таковой.

Анализ бизнес-процессов да и само словосочетание «бизнес-процесс» стало сейчас модным, как говорит, молодёжь – хайповым. А как иначе, если та же серия стандартов ISO 9000 и все производные на его основе (тот же обновленный ISO/IEC 17025:2017) исповедуют процессный подход. Откуда такая популярность? Что за ней стоит, если отчистить суть от терминологической шелухи?

Начну издалека. Разрисовывать красивые «схемки со стрелочками» в промышленных масштабах принято где-то с 1960-х, причем как это часто бывает пошло всё это поветрие с военной/аэрокосмической отрасли. Примерно, кстати, оттуда же и примерно тогда «прибежала» мысль в отношении реляционных баз данных, но это мы немного отвлекаемся. Методология «прямоугольничков и стрелочек» оформилась в качестве термина SADT (Structured Analysis and Design Technique), а позднее в виде нотации IDEF0 (Publication 183). Красиво это звучит так:

Конечно, сводить все нотации моделирования к IDEF0 неправильно, существуют и нотации DFD (Data Flow Diagram), ARIS etc. Однако по своей простоте и функциональности сравнить что-то с IDEF0 очень тяжело. В чём суть? Взгляните на рисунок ниже:

Прямоугольник – это есть функциональный блок, т.е. функция, действие. А стрелочки – это и есть интерфейсные дуги, говоря наукообразно. Тем не менее птичий язык будем использовать дозированно, главное – суть. Любое действие (функция) должно приводить к какому-либо результату – иначе оно бессмысленно. Этот результат (он может быть не один) – и есть стрелочки, выходящие из правой грани прямоугольника. Официально именуется выход (output). Например, выходом моего стучания по клавиатуре будет данная заметка в своём завершенном варианте. 🙂 Выходом обработки заготовки будет деталь. Вот на примере детали лучше всего проиллюстрировать все стрелочки, да и всю нотацию целиком. В случае изготовления детали (это и есть собственно функция, работа, деятельность) входами, т.е. стрелочками, входящими в левую грань прямоугольника, будет заготовка и/или другие исходные материалы, сырье. Верхняя грань – это управление. Результат нужно достигать в соответствии с конкретными критериями приемлемости. В случае с деталью – это чертеж, техническая документация с различными допусками и т.п. Иначе вы просто не сможете оценить, насколько тщательно вы поработали напильником. А нижняя грань – это механизмы. Механизмы, это то, что помогает преобразовать вход в выход, не затрачиваясь при этом. Ну или почти не затрачиваясь. Тот же напильник, инструменты, станок, кстати говоря, тот же сотрудник. Т.е. шире говоря, ресурс, который не становится частью готового результата непосредственно. При этом согласно нотации IDEF0 любая деятельность может быть без входа или механизма, а вот без управления или выхода – не может. В программных продуктах моделирования часто это пеленговалось, как синтаксическая ошибка в графическом языке моделирования. Это было удобно. В частности, в архаичных продуктах компании СА (BPwin, AllFusion Process Modeler) была встроенная функция Model Consistency Report (отчет целостности модели), которая автоматически сообщала вам, где вы забыли (или забили) указать управление и выходы. Для одной функции это избыточно. Но методология предусматривает вложенность большого числа подфункций – в этом основная фишка. Одну крупную функцию «Изготовление ракеты-носителя» можно ведь расшить (это называется декомпозиция) на многие подфункции. Приведу пример, наконец-то, ближе к фарме, который автор специально воспроизвел в учебных целях. Возьмём европейское руководство GDP EU (cамо оригинальное руководство 2013 г.р., в Украине оно переведено в 2014-м, а в рамках ЕЭК вступило в силу Решение № 80 в 2016-м – по сути значимых отличий в этих версиях по отношению к европейскому оригиналу нет). Там сформулирован ряд формальных требований к дистрибьюторам, которые те обязаны выполнять. Поскольку документ описывает их в свободном повествовательном режиме, то когда регулируемая компания начнет реализовывать эти требования, разрабатывая документы своей системы менеджмента качества, то может, как нетрудно предположить, что-то «забыть», «потерять» или просто по мере разработки документов различными людьми система в целом становится противоречивой по мере детализации. Из опыта автора для поиска противоречий практически любой СМК (не только у дистрибьюторов, но и у фармпроизводителей, испытательных лабораторий) поиск таких противоречий разной «степени тяжести» приносит результат в течении максимум полудня. Это легко можно обнаружить в рамках внутренних аудитов, например, когда вы возьмете нормативный документ, а затем почитаете, как требования этого нормативного документа а) у вас описаны; б) как их выполнить на практике. И это ещё полбеды, если ваша система – бумажная. Куда хуже, если вы «кривое описание» передаете программистам, чтобы они его «упаковали», например, в 1С. В бумажной системе условная Марьванна или Михалыч легко поставят и галочку, и птичку. В 1С – если в её основе будет противоречивый бизнес-процесс – в лучшем случае будут танцы с бубном вместе с ИТ-отделом. В худшем случае деятельность просто будет блокирована на неопределенное время. Кстати, попутно раскрыт и смысл валидации – поймать такие косяки и призвана валидация в процессе разработки таких решений (лучше всего на этапе анализа требований), а не в момент, когда случится результативный затык в продуктиве. Никакой другой пользы валидация, по сути, не несёт. Поэтому «рисовать» документы, чтобы узаконить бардак категорически не советую 🙂 Инспекторов ввести в заблуждение может и получится, но сами будете при этом спотыкаться, чертыхаться и подставлять табуретки по сервисы.

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

Начало не предвещает беды – всё просто – деятельность по GDP – это один прямоугольничек и никаких стрелочек мы к нему дорисовывать не будем – они появятся на нижних уровнях. Тут немаловажная деталь, с нижних уровней на верхние можно транслировать впоследствии любое количество стрелочек, в т.ч. выборочно, например, только крупноуровневые. Так, для верхнего уровня стрелочкой управления может быть само руководство GDP – тут сейчас не показано, чтобы мы могли не отвлекаясь пойти дальше по уровням декомпозиции. Что нам диктует уровни? Да сами требования GDP. Мы видим по тексту документа, что есть «процессные» разделы «Оптовая реализация лекарственных средств» и «Претензии, возврат, подозрения в фальсификации и отзыв лекарственных средств». Вот мы и разбиваем на две функциональные группы эти области деятельности:

Но нам по прежнему это мало о чем говорит и нужно дойти до конкретных подвидов деятельности и снова мы ничего не выдумываем и не высасываем из пальца, а читаем руководство GDP (en, ru). Пойдем для иллюстрации метода по ветке оптовой реализации лекарственных средств (в оригинале это Сhapter 5 Operations).

Как заметит внимательный читатель – у меня на диаграмме есть некоторые требования сверх нормированных в виде отдельных пунктов, а есть и пропуски – например на диаграмме А1 нет пункта «Экспорт», зато есть пункт «Отбор проб», отсутствующий в оригинале. Это частные ситуации, которые не должны вас смущать – для целей демонстрации это несущественно. Далее снова для удобства рассмотрения выделим первый процесс – приемку лекарственных средств (в оригинале – 5.4 Receipt of medicinal products). Расшиваем требования этого пункта:

И даже на этом всё может не исчерпываться:

Как видите только на 5-м уровне декомпозиции мы дошли до достаточной степени детализации, чтобы иметь возможность буквально выполнить сформулированные требования. Вот тут мы уже и дорисовываем стрелочки, которые могут выборочно транслироваться наверх и/или передаваться в смежные функциональные блоки. При этом исключено, что вы «потеряете» какой-то выход, потому что если он единожды определён, то он существует в рамках уже целой модели. Равно как у вас будет отсутствовать функциональный блок без управления (без стрелочки сверху) – ведь если такой «безхозный» блок наличествует, то это будет означать, что вы задаете деятельность, ничем не обоснованную и ничем не регламентируемую. В выбранном примере в качестве стрелок управления показаны пункты Решения № 80 ЕЭК – на самом деле такого разбиения не существует в оригинальном тексте GDP EU, но при этом все эти требования по сути своей есть в оригинале, правда, в режиме перечисления в одном предложении и/или в виде отдельных абзацев – следовательно такие требования ещё легче «потерять из виду». А даже если они забыты и не будут – документ ведь пишет по конкретному виду деятельности один человек, который, будем думать о людях хорошо, ответственный и внимательный. Если выходы описываемых им операций будут определены без проблем, не факт, что о них «вспомнит» другой коллега, описывающий параллельную деятельность. Упустим показанные в модели негативные сценарии (ветка А11, функциональный блок А112), когда приемка провалилась – этого, кстати, нет по тексту GDP, однако это прямо проистекает из логики процесса, что принимаемый товар может быть забракован – тут не путать с возвратами, которые GDP уже как раз описывает отдельным пунктом 6.3 – этот пункт описывает ситуацию, когда «вернули вам», при этом, очевидно, нет ситуации «вернули вы» — бумага это «стерпит», а к примеру 1С – нет. И если такой бизнес-процесс вы не предусмотрите при реализации компьютеризированной системы учета, то без вмешательства программиста и пинков руководства вы просто не реализуете этот процесс. Так вот, по тексту GDP после успешной приемки (п. 5.4) последует хранение (п. 5.5) – это тоже процесс. Там тоже нужно реализовывать определенную последовательность действий. Внимание, вопрос: «Какие выходы в результате выполнения приемки должны быть в качестве входов (или управления) перед началом хранения?». Ответ: «Подберите стрелочки выходов процесса приемки из вашей модели». Если вы начнёте сочинять «что-то отдельное», то с высокой долей вероятности, особенно если эти два смежных вида деятельности будет описывать два разных человека, каждый опишет «вещь в себе», которая априори не может быть самодостаточной. А вот что получится, если в рамках каждого функционального блока вывести все применимые к нему требования и обнаружить все выходы:

В приведенном примере видим требование «Отсутствие видимых повреждений». Правила системного анализа гласят, что выходом такой деятельности (по проверке видимых повреждений) должно быть формальное подтверждение – в рамках компьютеризированной системы – хотя бы чек-бокс (галочка), мол, зуб даю, повреждений нет 🙂 Понятно, что поскольку подобных критериев несколько в рамках всей деятельности по приемке, то доступный к дальнейшему хранению продукт должен «насобирать» всех требуемых галочек, для того чтобы хотя бы появиться в списке (быть доступным) для дальнейшего хранения и применения всех остальных алгоритмов, например, реализации принципов FEFO и т.п. Без автоматизированного инструмента такого анализа в лучшем случае вы будете уязвимы для аудиторов высокой степени зрелости, когда вам зададут вопрос: «Как вы формально оцениваете отсутствие повреждений при приемке?». В худшем случае запутаетесь сами и введете в заблуждение ваших коллег.

Но вернемся к началу нашего изложения. В первых абзацах вы, наверное, обратили внимание, что я говорил про «архаичные программные продукты», про «бывшую доступность инструментов» и вообще всячески употреблял прошедшее время. Дело в том, что ИТ-технологии настолько стремительно развиваются, что зачастую другие направления отстают от них даже не на шаг, а гораздо больше. 🙂 SADT и IDEF0 – это достаточно интересные инструменты, причем гораздо более удобные, чем неформализованная блок схема «которая никому и ничего не должна». Но время не стоит на месте и автоматизированный процесс описания бизнес-процессов эволюционировал в автоматизированный процесс написания бизнес-процессов. А именно, технологии позволили не только красиво «нарисовать стрелочки и прямоугольнички», но и сразу же, после того как оптимизированное решение будет всесторонне «обкашляно» всеми заинтересованными лицами, транслировать это в программный код и в программный продукт. Это позволяет нотация, получившее наименование ВPMN 2.0.

Cпрашивается, зачем автор забил столько эфирной площади устаревшими диаграммами и подходами? Сам часто себе задаю такой вопрос 🙂 Тем не менее, на данном этапе ответ прост. Чтобы подойти к основам BPMN 2.0 нужно какое-то базовое понимание бизнес-процессов на самом примитивном уровне. Примитивнее (и вместе с тем информативнее) описания при помощи IDEF0 по признанию многих специалистов предметной области попросту не существует в природе. Если вы хотите ограничиться только диаграммами и уже по ним потом ваять либо СОП, либо разрабатывать компьютеризированную систему – ничего проще вы не найдёте. Тот же ARIS имеет гораздо больше элементов – вы только его элементы графического языка будете изучать несопоставимо дольше. DFD хорошо визуализирует поток данных, но там нет ни управления, ни механизмов, а значит «за кадром» останется кто ответственный за выполнение той или иной операции и на предмет соответствия чему она должна выполняться. Есть ли недостатки у IDEF0? Безусловно. По мнению автора – очень эшелонировано эта нотация реализует логическое ветвление – пресловутый ромбик с выбором, мол, налево пойдёшь – коня потеряешь, направо пойдёшь… ну общий посыл понятен. Это ранее реализовывала нотация IDEF3 – имитационный анализ. Вообще правильнее было бы говорить о семействе нотаций IDEFx.

Но времена летят неумолимо, и вышеупомянутая контора СА даже намека не содержит на свои продукты, актуальные ещё лет 10 назад и реализовывавшие нотации как IDEFx, так и DFD. СА окончательно ударилась в Agile и т.п. Я могу предложить бесплатный продукт, который всё ещё доступен в сети для построения моделей IDEF0, но он уже давно снят с поддержки и морально устарел – это использованный во всех иллюстрациях выше Ramus. Но в целом в режиме именно аналитики, а не наскальной живописи продуктов, поддерживающих IDEF0 уже практически нет, а рисовать схемы в том же MS Visio (там тоже есть схема IDEF0) – теряются все преимущества, описанные выше. MS Visio не следит за корректностью декомпозиции, за правильностью размещения стрелок, за целостностью модели и т.п.

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

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

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

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

И вот тут лично у меня есть некоторые обоснованные сомнения/подозрения, которые я рассчитываю с вашей помощью развеять. По идее фишка с BPMN 2.0 рулит в полный рост – эту нотацию поддерживают SAP, Oracle, куча есть программных продуктов – те же Bisagi (базово бесплатный продукт) или Business Studio  (последний продукт – платный, но с возможностью построения смешанных моделей – например, вы начинаете построение в IDEF0, проще которой только плинтус, а потом, на определенном этапе декомпозиции, когда вам становится «тесно» в рамках такой простоты – вы переключаетесь на ВPMN 2.0). Насколько я понимаю – эти подходы массово используются условными авиакомпаниями, турагенствами, разработчиками софта. Специальность бизнес-аналитика очень востребована в ИТ-шных и околоИТшных направлениях. Это по-модному звучит BI (“би-ай”). И только в фарма «девочки в отделе обеспечения качества» продолжают набирать разрозненные СОПы в Word 🙂 При этом, как это часто случается, СОПы далеки от реальности, ничего кроме сумбура в себе не несут и существуют «для инспектора» (ещё один категорично отрицательный аспект – в моём представлении лучше не иметь ничего, чем кривое описание – распутывать кривой бизнес-процесс бывает гораздо дороже, чем получить замечание по отсутствию СОПа и исправить его в плановом порядке, но описав всамделишную процедуру, по которой может действовать любой сотрудник, не взирая ни на ротацию кадров, которая часто происходит с потерей преемственности, ни на любые другие субъективные предпочтения исполнителей). Есть ли толковые системы менеджмента, созданные «пешком», вручную, по наитию? Есть, но на современном этапе такой подход кажется чрезмерно экстенсивным. Прав я или нет – решать вам. Ну и рынку 🙂

Тут вспоминается преамбула книги «Дао Тойота»: «Вы можете не меняться – выживание не является обязанностью». Метрополитен ведь когда-то тоже копали лопатами 🙂

Подписывайтесь на каналы PHARM COMMUNITY:

   
Просмотров: 625
Поделитесь с коллегами:

Оставьте комментарий