В этой главе пойдёт речь о описании и моделировании бизнес архитектуры. Описанием занимаются бизнес аналитики, а моделированием занимается бизнес архитектор. Архитектору необходимы полномочия и умения ими пользоваться для организации рабочей группы по измеению бизнес архитектуры, которые обспечиваются руководством тех подразделений, чья архитектура изменяется. Без поддержки и умения ими пользоваться не имеет смысла что-либо описывать и проектировать. Чтобы эта поддержка была, необходим, чтобы был запрос на изменение. Заинтересованные лица в изменениях и их мотивация описывается в политическом слое. Без него никакие изменения не будут применены в реальности и так и останутся только на диаграммах. Также важно, чтобы заинтересованные стороны верили, что архитектор сможет им помочь. Для этого бизнес архитектору при проработке более нижних слоёв необходимо понимать нижлежащий слой (слой прижений). Этот слой преставляет из себя описание взамодействий функций реализумых информационными сихстемама. Эти функции и отображаются на нижележащих слоях процесса, образуя технологические карты. Посмотреть это можно на других технологических картах и концептуальных архитектурах. На концептуальных архитектурах обозначаются инормационный системы в виде группы (пучка) безнес фукнциональностей (функций) и созданные связи. Исходя из этого можно понять трудозатраты и можно ли будет продать измеенния заинтересованным лицам ршения их проблем с учётом трудозатрат на их решение.
Если клиентский путь находится на стороне потребления услуги клиентом, то бизнес процессы находятся на стороне обеспечения компанией этих клиентских путей. Связан клинетский путь и процессы точками взаимодействия, через которые колиент взаимодействует с компанией. Точки взаимодействия необходимы для получения необходимой услуги, которая предоставляется как сервис с помощью необходмой фукнциональности. Фактически точки взаимодействия отображаются в CJM как этапы пользовательского пути, а в BPM – как пользовательские действия. В CJM отображаются действия в пользовательком пути пользователя и их характеристики с точки зрения пользователя, а на BPM отображаются действия в бизнес процессе и характеристики процессов с точки зрения обеспечения этих процессов компанией. На этапах пользовательского пути в CJM мы увидем пользовательские метрики (время, сложность выполения и отношния пользователя), а на бизенес операциях в BPM мы увидем реализационные метрики (время выполенения, информационные системы, нефункциональыне и функциональне требования к процессу). В этих инструментах используютя разные метрики: в CJM это продуктовые метрики, такие как NPS (Net Promoter Score), а в BPM – контракт (SLA) на предоставление сервиса. Но клиентскй опыт в клинтским пути управляется через уровень предоставления севиса в точках контакта и меняя контракт в наиболее слабой точке можно улучшить весь клиентский опыт у пользователького пути. Может быть изменены сами точки взаимодействия, тогда, обычно, делают MVP бизнес процесса (создаётся отдельный сценарий процесса) и создаётся новый CJM для тестовой группы. Постепенно, анализируя показатели CJM выявляются узкие места, определяются какие параметры в BPM позволят закрыть узкие места производится корректировака BPM. Когда узкие места в новом клиентском опыте закрыты, то сравнивая его паказатели нового CJM (для нового отлаженного пользовательского пути ) с исходныйм CJM (для устаявшегося пользователького пути), то есть проводится A/B тестирование, определяют, удачный ли был новый процесс. Оптимизация процесса помогает снизить стоимость реализации продукта, а оптимизация клиенсткого пути – повысить стоимость для клиента, разность которых даст доходность и целесообразность к масштабированию.
Клиент проходит клиенткий путь (может отображаться на CJM в ARIS) для получения услуги или продукта (каталог услуг и продуктов в можно просто отобразить как реестр в ARIS для нужд проектирования). Параметры услуг, принятые в компаниях указывать в реестре их услуг, в ARIS нормализованы и разделены на реестр и диаграмму окружени продукта с параметрами: владелец (ответственный и эксперт), подразделение (человеческий ресурс), описание, KPI (бизнес метрики услуги), SLA (нефукнциональные параметры процесса). В ARIS можно на диаграмме оружения продукта отрисовать связь продукта с функциями: оказываемыми услугами в рамках продукт. Эти услуги и являются процессами, у которого есть владелец (владелец может отвечать за несколько процессов – удобно отображать привязку его к ним на карте процессов). Например, фунукциями в рамках предосталения продукта "кредитная карта" может быть: "получения кредита", "закрытие кредитной карты", "получение баллов для партнёров" и дригие. Каждый из них – отдельный процесс. На диаграммах отображается модель реального оказываемого процесса без ненужных деталей. Процесс представляет повторяющиеся последовательность действий и на нём интересна именно одинаковая часть. Модель может быть описана одной диаграммой или несколькими верхнеуровневыми диаграммами. На этих диаграммах процессов показываются точки взаимодействия пользователя с сервисами компании. Все технические моменты и сложности скрываются в свёрнутых подроцессах, чтобы верхнеуровневая диаграмма легко могла быть прочитана любым сотрудником. Так, процесс "получения кредита" обеспечиватся одними системами, но на верхнем уровне, там где точки взаимодействия, в зависимости от канала будут отличаться совместные действия пользователя и компании. Так, для канала "сайт компании" будет одна высокоуровневая последовательность операций, а в канале "отделения банка" – другая. Можно, конечно, пославить условие (шлюз), на то, от в какой канал обратился пользователь. Такие последовательности будут сложно читать на одной диаграмме модели процесса, так как увеличивают объём и отвлекают. Лучше разделить по каналам на отдельную для канала "заказ с сайта" и для канала "отделения банка". Многие подроцессы у для этих каналов будут одинаковые, если не на высокоуровневой диагарммах, то на более детализированных. Для повышения одинковости обеспечивающих операций и их систем и для удобства клиентов стараются делать каналы омниканальными.
Процессы можно описать используя разные нотации. Примерами нотаций могту быть BPMN, IDEF, EPC. EPC довольно своеобразная натация, в которой золожен принцыпы, которые сходу не даётся, что не позволяет использовать диаграммы на IDEF как средство коммуникации с IT и специалитами и доменными экспертами. EPC отражает только процессы, работающие по событийному принципу (события – обработка), что для многих недостаточно. BPMN 2.0 довольно универсален как по переносимости, так и по возмоности описания процессов. Его и будем рассмотривать.
BPMN – не только инструменты описания, но и интрумент оптимизации процессов в рамках концепции бережливого производства. CJM является илюстратором состояния клиентских путей, после изменения процессов, его обеспечивающих. Процессы улучшаются постоянно малыми изменениями (принцип Кайдзен), что минимизирует риски после изменений. Это важно, так как измеение в процессе влияет на клиенсткий путь, который отображает клиентский опыт. Основными эксператами являются исполнители этих процессов. Имеено они занают неточности, как сделать лучше из опыта, что устарело, а что ещё так и не внедрено, находят новые решения для стандартных и не очень ситуаций. Ставя цель изменить параметры клиентского пути мы изменяем процессы, которые его обеспечивают. Поступая так, мы получаем обратную связь, ведь изменяя параметры предоставляемых сервисов мы воздействуем на клиента, а он может дать разную обратну связь, которая наслоится спровоцирует изменение клиенского опыта на изменение сервисов, преоставляемых процессами, и реакцию самого клиента на эти изменения. Поэтому здесь тоже важно изменять мелкими шагами и измерять суманый полученный результат клиентского опыта каждого клиента – от этого будет зависить параметры клиентского пути в целом. Описаные процессы показывают их владельца, стоимость выполнения, продолжительность, а описанный клиентский путь – приносимый доход, отток клиентов.
Для построения безнес проессов в системе проектирования (например, ARIS) по клиентскому пути можно следовать слудующей последовательности:
* в CJM этапы клиентского пути привязать к ответсвеным за них депортаметам;
* определить за какие этапы (косания) отвечают какие безнис процессы;
* найти или добавить в картах процессов депоратаментов использованные процессы;
* для кождого процесса проверить и обносить диаграмму окружения, связывая с другими диаграммами и бизенс факторами (владельцами, депортаментами);
* верхнеровнево детализировать c помощью стикеров части клиенского пути в границах процесса до уровня операций;
* перенести верхнеуровневый процесс с детализацией ответственности до уровеня депортаментов;
* детализировать в системе проектирования депортаменты до информационных систем и движения клиентов до потоков управления;
* перенести показатели этапов в CJM до показателей информационных систем.
Как и в случае с клиентским путём, для которой есть CJM на текущий момент (AS IS), на ближайшие изменения (TO BE, обычно на ватал) и целевой CJM (DREAM, на горизонт стратегии развития), также строиются модели процессов для AS IS, TO BE и DREAM. В CJM указываются парметры удовлетворённости клиента и пользователького опыта, а в бизнес процессах – оценка по каким либо значимым критетриям, которые влияют на показатели пользователького опыта на CJM.
Поговорим о процессе, его модели, сценарии и его диаграммах. Процесс процесс представляет из себя последовательность действий приводящих из раза в раз к целевому состоянию. Процесс может быть автоматизирова или нет, но почти всегда требуется участие людай для подройки и решения проблем. Обычно, действия выполняемые в ручную точнон не повторяются, иначе бы они были автоматизированы. Например, человек проверяет документ и выносит решение. В некоторых вслучах ему может нехвать зананий технических регламентов, тогда он сверится с ними, в некоторых ему нужно будет больше данных – он позвонит автору, некоторых моментах ему не хватает опыта и уверенности – тогда он стросит коллег или руководства. Процесс сложен и для общего понимание документооборота важен факт, что документ проверяется, а не как это делается. Процесс представленный в таком упращённом виде, как набор действий, таких как "проверка документа" является его моделью. Модель же всего дукументооброта сложна, а нас в разных ситуациях может интересовать модель при определённых условиях. Например, у нас есть документы на обычные и иностранные и из-за этого у нас появляются развилки до чтения – нужно перевести, при анализе – нежна роль эксперта по иностранному законодательству, нужен его выбор, нужны и другие действия. Упростить можно, разложив по разным случаям использования (сегментам пользователей или услуге) – обычные и иностранные. В результате мы модель отразили при разных условиях – это сценарий процесса. У процесса может быть один сценарий, а может быть много – это зависи от процесса, детализации как в клубину (разбиение действий), так и ширину (указание возможных не основных ответвлений), так и от задач использования сценария. Сценарий отображается на диаграмме сценария модели процесса, обычно, для краткости, называемой просто диаграммой процесса, подразумевая, что их может быть несколько. Надиаграмме отображатся сами дейтсвия в виде значков операций и потоки управления в виде стрелок, обозначающие последовательность выполнения отображённых действий. Отображённая последовательсность действий называется потоком работ (WorkFlow). Экземпляр процесса – это траектория выполения диаграммы процесса.
Диагармма процесса но может разрабатывается на специальной нотации, универсальной счиатется BPMN 2.0. BPMN (Business Process Model and Notation) разрабатывается и поддерживается Object Management Group как единый стандарт метомодели для модилирования процессов. До появления BPMN существовало и сейчас существует множество коммерческих метомоделей (VAD, EPC, EDEF0), каждая их которых имела свои приемущества, недостатки, ограничения и сферу применения. С верисии BPMN 2.0 от 2011 года унифицирована не только метомодель, но и язык разметки, благодаря чему модели можно переносить между редакторами. Для примера возьмём систему проектирования ARIS.
Архитектор исследует возможность предоставить услуги, называемый бизнес компетенциями, то есть возможность предоставить необходимые операции программами и описывает их с помощью карт компетенций. Сами бизнес компетенции на диаграмме могут быть связанны с:
* процессом, их предоставлющим пользователям;
* подразделением, источником которых оно явлеется;
* с продуктом, в котором эти компетенции реализуются;
* с ролью и должностью, являющимися их владельцами;
* с сотрудником, ими обладающий.
Владелец процесса отвечает за достижение целевых показателей этим процессом перед владельцами клиентских путей, которые использует этит процесс, а архиектор за его описание или совместное с владельцем процесса проектирование. Владелец процесса знает, как процесс должне проходить, а архитектор, какие есть возможности у систем. Для описания процессов и связей их с приложениями, их реализующими, используются графические представления, такое как диаграмма в BPMN, и структурированные текстовые описания, такие как реестры процессов. Из процессов строятся пользовательские пути, по котором пользователь проходится, в свою очередь детализируется до уровня операция с привязкой к интерфейсам приложений с помощью технологические карты, необходимый для их разраотки.
При разработки BPMN диаграм (далее, просто, диаграм) оперирует понятиями:
* события в процессе: начальное событие, промежуточное (веха) и конечное событие (целевое действие);
* сценарии по бизнес фаторам: канал сбыта, сегмент аудитории и другие;
* тип операции: ручная, автоматическая, пользовательская (привязна к роли);
* информационные объекты корпоративной модели данных.
Процесс описывается моделью процеса – в ARIS это папка с диаграммами процесса и перечень детализаций процесса, при просмотре на диаграмме окружения процесса или карте процессов подразделения. Процесс может состоять из нескольких диаграмм, описывающих его. Потребность в нескольких диаграмма вместо одно возникает, когда процесс сценарий процесса сложный и зависит от внешних факторов. В этом случае, диаграмму процесса деля на несколько для разных условий. Например, для процесса заказа товара, осуществлённого через канал сайт с оплатой по карте будет одна диаграмма, а через канал звонок по телефону с оплатой курьеру – другая, так как в самом процессе заказа практически нет общих элеметов и одинаковой логики. При прохожении процесса, начиная с начального события, формируется экземпляр события. Процесс может иметь ветсления, то тогда, конкретный вариант прохожедения процесса – конкретный вариант экземпляров прохождения процесса. Выполнение движется по потоку работ (WorkFlow), то есть потоку операций, связанных потокам урпвления и управляемыми событиями и шлюзами.
* Сценарий процесса может содрежать логику сценария, условия выполнения сценария, системы и роли, выполняющие части этого сценария (действия). Логика сценарий стостоит из последовательности шагов, которые необходимо выполнить, чтобы пройти от начала до конца сценария. Шаги сценария процесса могут быть детализированны сценарием продпроцесса (частью процесса). Сценарий процесса отображается в виде диаграммы (обычно, BPM) сценария процесса, где он привязывается к другим объектам бизнес архитектуры, такими как роли, входные и выходные документы (например, для ручных операций, такие как накладные), различные артефакты (функциональные и нефукнциональные требования на операцию). Состоит из операции (можно разделить по исполнителем: атоматическая, пользовательская, ручная), события (входные, промежуточные и конечные), таймеры, шлюза (ветвления и слияния по операции в маркере) маршрутизации, связанных потоком управления (условный и безусловный, который пропускает по условию) и маркеров множественного выполения (с последовательным или параллельным выполнением) до выполения условия.
* Операции (обзначаются прямоуголником с описанием задачи внутри него) – выполняемая операция в процессе. В начале проектирования можно указать верхнеуровнево, что это просто операция. На этапе проработки реализации уже можно определить, может ли эта операция быть выполенена за один раз, или же потребуется больше количество шагов. Если же мы уже знаем, что операция будет выполенна за один раз, мы знаем, кем или чем она будет выполннена. В отличии процесса, который може начинаться на какому-то начальному события, например, по таймеру или другому внешнему событию, подроцесс же начинаетяся, когда поток упрвления входит в составную операцию (свёрнытый процесс или смежный подроцесс, который берётся из общего реестра подроцессов, в операцию), обозначающую этот подроцесс. Когда поток в подроцессе завершается, то он предаётся обратно в процесс. В случае, когда у подроцесса несколько потоков и несколько выходов – после составной операции ставится шлюз, определяющий логику объединения потоков подпроцесса в один поток процесса, содержащий его, когда все ветви подроцесса завершились. Вложенность подроцессов не ограничивается. Теперь осталось конкретизировать эту оперцию маркером. Маркер "плюс" указывает, что эта составная операция будут реализована с помощью подропцесса, а другие – вручную или автоматически за раз. Из них частые, маркер "рука", "свиток", "шестерня" или "человек" указывают, что это атомарная операция (задача), которая будет выполнена за раз сотрудником полностью вручную без информационной системы (для "рука") или автоматически с уведомлением пользователя ("свиток") или других информационнных систем ("шестерня"), или выполненна пользователем. Более спечиалаизированные: промежуточное событие отправки сообщения (закрашенный конверт) в другой процесс (или подроцесс) у которого начальное событие активируется по полчению сообщения и получение сообщения с результатом от получившего процесса чеерз промежуточное события получения сообщения (контур конверта) при организации синхронизации процессов на основе потока сообщений. У операции могут быть и маркеры множественного выполнения, показвающие как несколько поступивших задач (через событие типа сообщение, из Объекта данных) будут выполняться операцией: послевательно (горизонтальные линии) или параллельно (вертикальные линии), также возможено просто выполение задачи нескоколько раз (обозначается круговой стрелкой) или выбираются пользователем в интерактивном режиме по требованию (волнистая линия) из набора операций. При составной операции с маркером "по требованию" выполняются действия из подпроцесса в порядке и колчестве повторнений определяемым пользователем интеративно, поэтому в подпроцессе не указывается потоки управления и события, а просто набор доступных пользователю операций. Операции, как и подроцессы, бирутся их реестров, если есть возможность, для их повторного использовния. Если это так, то оперкция (простая или составная) помещается жирным контуром, чтобы было понятно, что для изменения её потребуется согласования со всеми её пользвателями. Например, процесс предоствления банковской карты может использоваться в процессе взятия кридита и создания дебетового счёта. Также и операция, выполняемая конкретной системой, например, перечисления средств со счёта на счёт, может использоваться при переводах, оплатах услуг и взятия кредита. Сама операция связывается с конкретной системой – в таком случае схему процесса называеют технологической картой, так в ARIS для этого используется детализация. Индивидуально может быть привязана Роль или информационная система, испольняющее это действие. Дейсвие начинается когда входящий поток управление передаёт управление и полнотью заканчивается перед передачей в выходной поток.
* Поток управления (обозначаются стрелочкой) показывавают порядок выполенения процесса. Поток обозначается стрелками. В случае простой стрелки (простого потока управления) последовательность определена однозначно и не может быть дополнительных стрелок. Чтобы иметь пльтернативное выполнение процесса делаются равилки. В развилках указываеются условаи, при которых будут выполняться поток. Чтобы показать какое условия должно выполниться, чтобы поток упраления стал кативным – стрелка имеет в начале ромбик и надпись уловия над ней. Сделать это в ARIS можно указав в свойствах тип Условный поток и задав свойство Навание условия. Может случиться так, что сработают несколько условий – тогда поток управления разделится, а может не сработать ни одного. Важно, чтобы хотябы один поток упрвления дошёл до конечного события – для этого ставят поток по умолчанию, который срабатывает, когда ни один альтенативный поток не сработал. Помечают его косой чартой, а в ARIS это можно сделать выбрав в свойствах тип потока По умолчанию. Для более тонкой настройки логики при множетсвенных срабатываниях поток связывают с шлюзом, содержащий в себе логическую операцию.
* На диаграмме операции привязываются к объектам иноформации с помощью ассоциаций для того, чтобы можно было в последствии привязать классы информации корпоративной модели данных, например, чтобы было видно, что класс критичных данных обабатывается определённой ролью или системой. Направленность ассоциации к объекту информации означает то, что информация будут измеенена – это важно для информации, доступ на измеении которой критичен. Считываение информации с объекта информации показывается ассоциацией, направленной от объекта ассоциации, что важно при сопоставлении с доступами, например, на конфедициальную информация и информацию, передача которой онграцичена, например, банковская тайна, персованальные данные, тайна переговоров и дргуие. Привязка схемы к роли или системе осуществляется располжением операций на троках этих систем или (и) ролей.
* События (обозначаются окружностью) останавливает продолжение потока управления до изменение в целевой статус процесса. Если физическое событие процесса содержит работу, то его нужно разбить на событие на диаграмме и действи, так как на диаграмме применяются чистые события. Например, на событие реального процесса "Получение ответа от клинента" необходимо на диаграмме представить в виде события "Пришёл ответ клиента" и операцию "Получение ответа клиента". Любой процесс имее:
** Хотябы одно начальное событие имеет каждая диаграмма процесса, обозначающее начало выполнение потока управления выходящего из него. Начальное событие активируется внешней ситуацией: для процесса – это наступление определённого времени или другой ситуации, например, действия пользователя, которое задаётся в названии его и отображается как надпись под ним, а для подроцесса этим внешним действием является вход потока управления в подроцесс родителькой диаграммы, которая детализирована этим подроцессом, активизурет начальное событие подроцесса (без назвния). У процесса начальное событие может быть типизированно по сыбытию, которое запускает этот прцоесс, например, в другом процессе начата эскалация или обнаружена ошибка, и упрвляющий поток актвировал конечное исключительное событие, тогда связанно с ними низванием начальное событие будет активировано. Если в процессе или подроцессе содержатся несколько начальных событий, то при каждом срабатывании события создаётся копия выполнения процесса.
** Хотябы одно конечно событие, обозначающее завершение выполнения потока управления входящего в него. Если конечное событие помечено условием (текстом) его наступления, то для завершения потока требуется наступление этого момента. Если конечное событие не помеченно каким либо условием, как все конечные условия подроцессов, то выход происходит при достижении потока конечного события единомоментно. Для заверешния всего процесса трубется заверления всех потоков этого процесса. Поток из свёрнутого процесса создастся только тогда, когда все потоки в подпроцессе этого свёрнутого процесса завершатся. Можно завершить все потоки событием, которое момечено маркером принудительной остановки процесса.
** Возможно промежуточные события задержки (таймер, ожидания события) и передачи сигнала. Простое промежуточное событие уведомляет о наступлении события путём задерживания распространения потока управления, что активно исползуются в собитийном шлюзе, о котором пойдёт речь в этой главе. Событие может иметь побочное действие – передачу информацию в другое событие, что используются для синхронизации управляющих потков процессов. Если управляющий поток – синхроннен, то отравка и получение событий через сигналы – ассинхронны и могут принимаются многими процессами одновременно. Размещение события с перриодом срабатывания не делает цикл, например, каждый час – просто ожидание момента, когда может продолжиться распространния управляющего потока.
** Конечное ислючительное событие используется тогда, когда необходимо завершить все одновременно выполняющиеся потоки работ (потоки упраления и действия), когда происходит событие на одном из них. Синхронзировать потоки можно с помощью событийных шлюзов и потоков данных, но это сильно усложняет восприятие.
** Начальное конечное событие срабатывает в ислючительной ситуации. Эта ситуации описана в названии (подписи) у события. Наступление этой ситуации может быть понятно из контекста, например, произвошла непредвиденная техническая ошибка, а может быть явно указана в названии исключительного конечного события. При срабатываении начального события происходит завершение всех потоков работ в процессе, если они не были завершены исключительным конечным событием с тем же назанием. Поток работ (в событийном подроцессе), формируемый исключителным начальным событием, обычно, является действия решения последствий, например, уведомление пользовтеля об ошибки или откат транзакции.
* Шлюзы (обозначается ромобом в который сходят или выходят управляющие потоки), как астракция ветвления (один входит и больше одного выходят) или слияния (входят больше одного и выходит один) управляющих потоков. В отличии от просто сходящихся в действие или расходящихся стрелок от действия, шлюз определяет логику маршрутизации и наличие объединения приходов управляющего потока. Если стреки управляющих потокво сходятся и расходятся, то они независимы – этому соответствует шлюз с логикой "неисключащеее или", но может потребоваться и другие условия. Условия прохождения после ветвлении по конкретным маршрутам задаётся условиями на их реализующих потоках управление, выходящих их шлюза ветвления. Условие прохожедение задаётся подписью на потоке управления, а условие прохождение, когда по альтернативным маршрутам условия не сработали – наклонной чертой. Для логики управления синхронизации и объединения детализироваться маркером помещённым внутрь шлюза. Логики всего четыре: логики синхронизации (И), логика незаисимости (неисключающее ИЛИ), логика сихронизации для выбора (исключающее ИЛИ), логика выбора управляющего потока по первому произошедшему событию на нём. При использовании неислючающих (И и ИЛИ) шлюзов происходит разделение потока работ и они начинают выполняться одновеременно и может возникнуть необходимость при возникновении определённых событий в одном потоке – завершить работу во всех отальных: для этого используется исключительных (прервывающий) конечное событие, так как обычное конечное событие завешит только тот поток уравления, который в него вошёл.
** Маркер Исключающее ИЛИ (XOR, OR-OR, взаимосключение, обозначается крестиком, символизирует невозможность одинаковых вариантов) – достаточно поступления любого без синхронизации при слиянии без объединения за счёт синхронности запросов (только маршрутизация) и формирования любого одного потока из шлюза ветвления, если условия на выход сработало или потока по умолчанию (помечается наклонной чертой), если условия на всех других сработали отрацательно. Из этого свойства вытекает, что если прийдёт два потока управления, то не только они не будут синхронизированны, но и выполнятся два раза, при этом порядок их на выхде не определён. Так они упрвляюище потоки соединяются с операцией черзе шлюз с маркером Иключающее ИЛИ независимо и побочных действией не имеет, то, часто, шлюз убирают и просто проводят управляющие потоки прямо к операции – это уменьшает размер диаграммы, но усложняет понимание. В случае орагнизации с помощью обратной связи и двух шлюзов цикла, то такой цикл можно заменить на элемент множетсвенного выполенения для операции, но если несоколько – то их необходимо сгруппировать в подроцесс и это изменит логику выполения цикла, так как результаты из него будут получены для параллельного или последовательного множественного выполнения после завершения всего цикла, хоть сами итерации могут быть завершены в разное время при параллельном выполнении, и тем более при последовательном выполенении. Если условия у потоков упрвления на выходе из шлюза XOR ветвления не взаимоисключающие, то возникает непределённость в порядке – активировн может быть любой поток управления, который удовлетворяет его условию. Если же на выходе из шлюза XOR не активирован не один поток управления из-за условия и нет управляющего потока "в ином случае", то шлюз блокируется.
** Маркер Не исключающее ИЛИ (OR, AND-OR, альтернативы, обозначается кружком, символизирующим всеобщность) – активация одного любого входящего управляющего потока или сразу несколькоих синхронно в шлюз слияния с объединение одновременно пришедших и формирвоания одного или более потока, если условия на них заданных в комментриях или событии их удовлетворяют. Синхронизация при слиянии необходимо, чтобы информация со всех входный потоков управления объединилоась в один и была произведена унификация – выходной поток управления сработает единыжды. Опускать шлюзы при слиянии нельзя (можно только для шлюза XOR), а при ветвлении крайне не рекомндуется, так если два и более условных потоков выходят, то это опущенный шлюз ветвления ИЛИ, а если одни – XOR.
** Маркер И (AND, одновременное, обозначается плюсиком) – ожидание и объединение в один вызов поступления со всех входных потоков в шлюз слияния и или параллельное одновременное формирования потоков в шлюзе ветвления. Важным побочны эффектом синхрониизации при слиянии является то, что есил один из потоков уравления не прийдёт, то не продёт ничего через шлюз. Например, если на пути из одного вхоядщего в шлюз И не пройдёт условия, то выходной поток из шлюза никогда при данном экземпляре процесса не будет сформирован. Если же сработают все входящие потоки упрвления, то шлюз сформирует только один выходной поток упрвления. Обыно используют два шлюза, между которыми ставятся параллельно выполняющиеся операции, что позволяет синхронизировать выходной поток как объединение результатов, который потом можно будет разложить другим последующим шлюзом. Обхединение шлуюза слияния и шлюза ветвеления, имещих одинаковый маркер, допускается, но это может привести к ошибкам восприятия. Так как слияние синхронное, то оно будет дожидаться информации со всех сходных потоков упрвления – важно, чтобы на них не было бескоенечных циклов или после вервления через шлюз OR. Натационно, можно опустить шлюз И при ветвлении и отвести от операции управляющие потоки напрямую, а так как исходящие потоки без могут быть только от шлюза вервления И и такая ситуация однозначна. Но делать этого не стоит, так как сильно затрудняет чтения, так как входящие напрямую потоки без уловий в операцию означают объединение через шлюз XOR, так как все входящие потоки безусловны. В схемах донесения информации важнее парвильности следования нотации, так как являются средвтвом коммункации и фиксации договорённостей.
** Маркер Событие (по событию, обозначается пятиугольником в окружности) – ветвление по логики Исключающее ИЛИ на управляющие потоки по срабатыванию события в них, которое указывается в промежуточном событии. Архитектурно шлюз является шлюзом вервеления, после которого на каждойм из выходых управляющих потоков распологается по промежуточному событию. Работает шлюз таким образом, что активация вхоного управляющего потока проходит на каждый выходной и активирует все промежуточные события этого шлюза. Промежудточные шлюзы ужерживают от распросранения своими условиями. Как только срабатывает один из этих промежуточных событий, он пропускает сигнал, а событийный шлюз в этот момент снимает активацию на других промеждуточных событиях событийного шлюза активацию. Другими словами, сигнал пройдёт там, где сработае быстрее промежуточное событие событийного шлюза. Важно заметить, что если прийдут два сигнала на входной упрвляющий поток на событийный шлюз, как и на любой другой, то будет созданы под каждый сигнал своя компия и сигналы будут обарботаны.
* Объект данных (значёк файла или списка) – внутренний информационный объект экземляра процесса, обозначает данные, которые передаются подающся или отдаются операцией. Используется для уточнения связи операций и шлюзов. Особенно полезно, когда необходимо связать разные потоки работ (возможно процессы), в силу определйнных обстоятельств не могут наглядно быть связаны с по средствам потоков упрвления из-за их последовательной природы. Этими обтоятельствами являются: связь одного экземпляра с несколькими экземпляроами, например, процесс анализа предыдущих итераций, ассихронно развязанные, например, в лучае действий пользователя, управленчески разделённы. Сами заначки зависят от типа: единичные данные или их список и от типа данных. Связь отображается пунктирной линией, называемой ассоциацией с данными. Изменение или чатение данных указывается направлением пунктирной стрелки ассоциации: от операции (данные от оперции к харнению) – изменение, к операции (получение данных операцией на вход) – чтение, две стрелки (одна на чтение и одна на запись) или двухтороняя стерлка означает измеение (чтение и запись) данных. С одной операцией может быть ассоциированно один или более типов документов или их списков, а может быть и нисколько не ассоциированно – это зависит в том числе и от детализации и о бизнес необходимости. Например, действие "принятие решения" может быть ассоциированно с конкретным документом или со списком документов "нормативные документы компании". Множетсвенность принимает заначение, когда документы ассоциируются с циклом (обозначаются пунктиным контуром во крук повторяющиейся операции), в большинстве случаев означаемое, что действие в цикле повторяется по каждому документу из списка. С документом может быть ассоциирован класс данных из корпоративной модели данных, например, по критичности (секретности). Например, операция "выгрузка данных", с просто привязанным объектом данных "данные клиентов" несёт информативный характер, а если к документу привязан класс корпоративной модели данных "секретные данные", то и ограничительный характер на тех, какая роль может его выполнять. Кромер того, может использоваться как вариант связи между процессами или между процессом и подпроцессом. Напрмер, обхект данных "данные клиентов" привязан к одному действию на запись, а к другому – на чтение, значит эти "данные клиентов" предаются от одного действия к другому. В случае помещение данных в хранилище (базу данных, сетевую папку, сейф), то используется другой значёк.
* Бизнес факторы (условия выполнения обозначаются иконками) не воходят в нотацию BPMN, но могут быть добавлены в ARIS. Бизнес факторы указываемые в диаграмме определяют условия отображения на этом сценарии процесса, например, что сценарий процесса относится к определённому временному горизонту планирования, к определённому депортаменту, к определённому каналу обслуживания, к определённому клиентскому сегменту, к определённому продукту или услуге, реализована на определённой платформе, с сотрудком владеющим процессом, с определённым продуктом который обеспечивается, с определёнными нефукнциональными требованиями или другими характеристиками. Указания этих факторов, обычно, означает, что могут быть и другие диаграммы сценариев процесса, например, к горизонту планировния на первый квартал 2021 года или целевой (на горизонт планирования RoadMap) с обслуживанием в магазине (канал облуслуживания) на молодёж со вреднем уровнем достатка (сегмент пользователей) на плеер (продукт). Модель процесса делят на разные горизонты, точнее создают новых горизонт на при новой итерации его улучшения. Обычно модель процесса делят ещё по продуктам, по пользовательским сегментам, по каналам распространения, так как они сильно отличаются, но из-за унификации многие действия (подроцессы) совподают. Хорошей практикой является выбирать их из справочников.
* Дорожки (обозначаются прямоугольниками вокруг группы элементов потока работ) указания ответсвенности за части процесса. Дорожки могут быть горизонтальными или верикальными, делящие поле процесса на горонтальные или вертикальные участки. Применяются для деления на участников процесса или исполняющий систем, так в процессе могут указываться операции осуществляемые самим заёмщиком и заёмодателем, для их ражделения диграмма разграничивается на две дорожки (части диаграммы) и операции раставляются по ним. Для еденичных связей удобно указвать имеено связями, не взирая не дорожки. Если к дрожке приязана информационная система или роль, то все опреации, находящиеся на ней выполняются этой ролью или и информационной системой. К дорожке может быть не привязана не роль, ни информационная чистема, в этом случае или это пока ещё не уточнено, или эти операции выполняются пользователями (на это указывает маркер в операции), или к операциям идут непсредственные связи от значков ролей или информационных систем. Операция может выполняться несоколькими ролями одновременно или обеспечиваться несколькими информационными системами. Это можно указать ка с помощью такой дрожки, или с помощью связей, или с помощью комбинации дорожки и связи.
* Комментарий – часто используется для задания названия диаграмме и кратко описать её назначение. Это важно особенно важно при названии подроцесса, так как по названию подроцесса можно определить какое составное действие в родителькой диаграмме он детализирует, сопоставив название операции и назвние подроцесса. Комментарий может быть привязн к данным, например, для описания, как они получаются и используются, как с помощью их происходит взаимодействие. Коментарий может быть привязан к циклу (пунктирной акконтовке) для уточнения условия повторения, например, пока в очереди событий есть сообщения или, например, над всеми одобренными документами.
Нужно стараться, чтобы можно было диагармму, илюстрирующая процесс или подроцесс, читать на одной экране без прокрутки поля. Это позволяет охватить его полнсотью взглядом и редактировать его структуру. Подпроцессы – один интсрументов упрвления со сложностью, наряду с разделелением по по критериям, наример, по пользовательским сегментам или по потокам. Подроцессы выстраивают иерархическую структуру моделей процессов. Но, подровцесс (свёрнутая составная операция) является частью только одного процесса, содержит весь контекст (все данные) о радительком процессе. Чтобы переиспользовать подроцесс в нескольких процессах нужно определить его как отдльеный процесс, определить интерфейс для приёма данных и взывать его. Когда процесс разбивается на шаги, то он разбивается по их важности, а не по размеру. Например, производство и продажи, при этом может быть производство потоянным клиентам может быть гораздо больше отрузки, но не менее важно – производство будет детализровано пойзже. Шаг, который есть енеобходимость детализировать, оформляется как подроцесс: на основной диаграмме этот шаг помечается как составной шаг, создаётся новая диаграмма, в которой описывается составной шаг как процесс (подсроцесс), название которого берётся из названия составного шага, которого он описывает. Процесс описывает типовую последовательность действий – исключения в него не вносястя, если они не стали иметь постоянный характер. По возможности, лучше для понимания отображать на диаграмме процесс как ленейную последовательность действия. Сами действия должны быть конеретны в результате, но не в реализации, иначе они будут исполняться формально. Важно действия, указываемые в процессе, согласовать с владельцами подразделений обеспечивающи процесс, их ключевыми сотрудниками и другими важными заинтересованными сторонами, а в случае необходимости – корректировать ожидания. Умение согласовывать, фасилитировать, доносить информацию и убеждать – важные качества архитектора процесса, как и других архитекторов. В качестве архитектора может выступать как сотрудник наделённый руководящими полномочиями, так и нет. Сама роль архитектора наделяет сотрдника определёнными полномочиями, а если нужно соответствие – нужно запросить дополнительное подстверждение полномочий в виде должности. Обычно, в диаграмме окружения как раз и указывается должность архитектра процесса, как стратегического управляющего, и роль владельца (менеджера) процесса, как операционного управляющего. Но оба менеджуера, и архитетектор, и опереационный менеджер, оценивают работу процесса по эфективности и по результативности. Оба этих KPI числовые и хорошо поддаются измеренияю для контроля. Ответсвенность за каждый шаг имеет друге управленцы, обычно отвечающие за группу шагов объединённых по какомуто принципу, обеспечивающих их, например, информационной системой или подразделением работников. В описании шага нужно придерживаться баланса свободы и контроля, чтобы с одной стороны выполнялось так как за думанно для последующих шагов, с другой – можно было улучшать и развивать. Для развития нужно поределить тукущее состояние и необходимое. При проектировании текущего состояния необходиомо совместно со всеми участниками описать текущий процесс: текущее состояние, текущие цели, текущий способ достижения целей. После проводится проектировние нового состояния: описание, тестирование, стабилизация, корректировка, масштабирование – это тоже совместная работа, в которой архитектор фасилитирует и корректирует. Для изменения необходимо опредлить готовности сотрудников к изменениям, культура, неосознанная экспертность (привычка) – всё, что способствует энертности. Организация отдела, подразделения или компании – живого инертный распределённый организма, в котором протекают процессы, потому что им было удобно там протекать. Неучитвывая это, можно убить этот ораганизм, перекрыв обеспечение процессов, которые ещё не описаны или обеспечивающие процессы. Изменение – нестабильность, часто по старому, часть по новому – нужно время для стабилизации и на переход. Процессы протекают по реальной орагнизационной структуре от одних ролей и к другим, поэтому много работы нужно проводить именно с людьми, их привычками, культурой, навыками и опытом. Например, производить стимуляцию к поиску и нахождения проблем для самоулучшения. Но, даже самоулучшение нужно контролировать, используя методики управления изменениями, и контролируя результат, например, в отслеживая его в CJM. Но, важно, чтобы постепенные улучшения были над одним параметром во избежании взаимосвязей с дурими праметрами и ограничения ресурсов.
Процессы могут синхронизироваться между собой. Это может происходить через оправку сообщение (сигнала), который порождает другой или другие процессы (поток сообщений) или через изменение данных в хранилище данных, которые синхронизиурет данные (поток ассоциации с данными), но не является инициализирующим действие, а могут быть запущены другими событиями, например, таймером. Вызов процесса (поток управления) не используется для синхронизации процессов, так как вызов действует толко в границах процесса.
Диаграммы можно экспортировать в jpg или png.
Технологические карты структурно детализируют описание процесса технологическими обектами и атрибутами. Сам процесс содержит сценарии, операции, роли, данные, а технологическая карта к ним добавляет API, функции, атрибуты. Тем самым, технологическая карта связывает операции процесса с программами сервисов, реализиующие эти операциии. В технологической карте не описывается реализация на программного обеспечения, ни контаркта (API, application programming interface) – они являются точками для создания операций. Например, проектировать карты можно в различных системах, таких как ARIS. Соответсвенно, в ARIS нужно описать операцию, как набор связанных функций системы, где каждая функция будет привязана к определённой технической системе, реализующей её. Сопоставление происходит по контракту (функциональных и нефукнциональных обязательств) взаимодействия с функцией системы, например, API (Application Programming Interface), MQI (Message Queue Interface) или через общий файловый (CIFS или NFS) или объектный ресурс (Amazon S3 или OpenStack Swift). Технически это выглядит так: создаются фукнции на карте операций, соединяются между собой потоками управления, устававливается вход в процесс и выход из операции. Само поле разлиновано по областям систем, а функции размещаются в областях систем, которые эти функции реализуют. ARIS предоставляет создать не только операции, поэтому операции сгруппированы в процессы, процессы сгрупированы в услуги, услуги сгруппированы в продукты, а проудукты сгрупированы в клиентские пути. Процесс детализируется бизнес-логикой до отдельной операции, также диаграмой, как и операция детализируется на фукнции системы.
Процесно, технологическая карта создаётся, когда уже процесс уже спроектирован – то есть определены операции, например, в томже ARIS. Логику процесса проектирует бизнес архитектор до уровевня операций, а параметры этого процесса определяется руководсвом компании, другими заинтересованными лицами, стандартами, регламентами. Бизнес архитектор добавляет процесс в реестр процессов компании. Теперь процесс нужно детализировать до операций. Например, в ARIS это делается на значке операции в диаграме процессов из его контекстного меню "детализация…". Строится диаграмма операции. Теперь эту операцию нужно наложить на возможности ИТ ландшафта. Оперцию можно воспринимать как изменение данных в широком смысле: преобразование, фильрацию, добавление новых. Для этого создаётся логическая модель даных и технологическая карта. Логическими моделя данных занимается архитектор данных. Он строит логическим модели данных на корпоративном уровене (логическая корпоративная модель данных) и помогает строить логические модели данных решений архитекторам этих систем. Можно найти на корпоративной модели данных, какие данные требуются и через маппинг атрибутов корпоративной логической модели данных на атрибуты логической модели данных информационной системы определить, в каких системах они используются. Можно определить, какие данные в процессе учавствуют и на каких его фукнциях, как эти данные должны трансоформироваться, и как эти данные стыкуются с логическими моделями систем, которые обладют этими данными и могут их обрабатывать – это потребуется для определения, какими системами могту быть реализованы требуемые фукнции. В технологичекой карте указывается, какие необходимы фукнции, какими контрактами (из реестра API) они предоставляются, к каким классам данных логической модели данных производится обмен информацией и каких систем эти функции обеспечиваться. Этим занимается корпоративный арихитектор, который ответственнен за дизайн ИТ ландшафта. Он договариривается с архитекторами этих систем на возможность использования существующих, изменение текущих или созадния новых функций. Обычно это присходит в какой-либо системе управления производственным процессов, например, в случае с Jira создаётся СR на измеенние. Архитектор его оценивает и даёт оценку по возможным характеристикам, которые они могут обеспечить, узнаёт возмоность у менджера команды возможные сроки изготовления. Когда с реализацией договорились, архитетор системы разрабатывает архитектуру и ставит задачу или задачи по выполению CR на команду (команды). Бизнес аналитик детализирует нефункциональные требования. После создания фукнции, проверяется работа функции командой, архитектором решения и бизнес аналитиком, на её работоспособность изолрованно. Далее, команда во главе с архитектором, проводит интеграционно функциональное тестирования на возможость работы функции с взаимодействующими с ней системами. Когда функциональная работа проверена и интеграция прошла успешно, проводятся нагрузочные испытания и приемо-сдаточные испрытания на предмет готовности функуции к продуктовой эксплуатации. Здесь идёт сверка функции системы в соответсвии с технологичекой картой процесса. После этого идёт этап внедрения в промышленную среду. Для эксплуатации в промышенной сети настраивается мониторинг на контракт: обеспечения функциональных требования и нефукнциональных требования, необходимых для обеспечения работы процесса. Требовния могут проверять перриодическим тестированием или мониторингом.
Конкретно бизнес-анализу посвязён доскумент BABOK 3.0 (Business Analysis Body of Knowledge) от IIBA (International Institute of Business Analysis) и в часности заинтересованным лицам. Близкими по духу являются документы PMBOK и ITIL. Если BPM CBOK (Business Process Management Common Body of Knowledge) описывает только процессы, то BABOK и другие аспекты анализа. BABOK описывает процессы и практики бизнес анализа. Он объединяет шеть концепций по модели BACCM: потребности, ценности, решения и изменения, заинтересованные лици, контекст. В BABOK они связаны: заинтересованные лица обладаю потребностью, котора, которая, через имеенния, удовлетворяется решением, которое применяясь в конетексте, даёт ценность заинтересованным лицам. Кроме концепций, определяют шесть направлений для анализа для получения знаний (областей знаний): бизнес анализ, стратегический анализ, внедрение решения и другие. Для работы в этих обалстях уместны разные или конретные техники, например, доволоно универсально интервью, а финансовый анализ или сбалансированные показатели гораздо менее универсален.
Архитектура севриса состот из:
* конфептуальной архитектуры * бэклога задач * детальной архитектуры * архитектуры бизнес процессов * фич