Transcription
Коллеги, всем добрый вечер. Предлагаю начинать. Пожалуйста, да, поставьте плюсики, если меня хорошо видно, слышно. Ага, вижу плюсики, коллеги, спасибо.
Тема сегодняшнего вебинара у нас - это BPM для 1С. Как правильно моделировать интеграции.
М, кратко обо мне. Меня зовут Олег Коратаев. Я являюсь техническим архитектором в крупном и теххолдинге. Занимаюсь 1С более 20 лет. А был, занимал различные позиции от разработчика до руководителя практики, руководителя проектов. Являюсь руководителем курса архитектора 1Сы. А из таких значимых моментов, э, довольно сильно последние годы позиционирую себя как контрибьютор в различных open source проектах. Возможно, вы какие-то из них используете. это Vanessa Automation, я Unit, Chenkin Sleep и множество других различных проектов. Стараюсь везде помогать участвовать и их развивать.
Правила вебинара, коллеги, у нас. А, пожалуйста, активно участвуем. Задавайте вопросы, если видите, что, может быть, что-то я не договорил, то есть вы экспертны, допустим, в этом вопросе, пожалуйста, дополняйте, это будет здорово. Это очень приветствуется. И, конечно, да, все вопросы я буду по мере движения по вебинару смотреть в чате и стараться на них оперативно вчать. А запись вебинара придёт к вам на почту в виде ссылок. Плюс вы всегда её можете найти э в ВК видео. То есть ВК видео запись OTUS US регулярно на следующий буквально день публикуются. Можно будет посмотреть более детально.
Ну а теперь давайте, коллеги, я с вами познакомился. Давайте теперь, э, я познакомлюсь с вами. Пожалуйста, напишите, какая ваша сейчас актуальная должность и с какой целью вы пришли сегодня на данный вебинар. Всего лишь два коротких вопроса. Пожалуйста, напишите, познакомимся.
Так, вижу, коллеги уже пишут. Архитектор. Ага. с целью начала учёбы. Ага. Александр, программист. Да, коллеги, обязательно пишите с целью, какой пришли, потому что важно всегда, коллеги, если мы куда-то приходим на какое-то мероприятие, всегда у вас должна быть в голове какая-то минимальная цель, чтобы потом попробовать понять, а достигли ли мы этой цели. Это довольно-таки удобно. Так, Александр пишет: "Апгрейд". А, ну это про как раз, ээ, к э, видимо, к знаниям. Николай консультант 1Sрус там отраслевой эксперт по автоматизации. Интересует опыт грации с BPMS. М. Здорово, да, Руслан? Ну, к сожалению, у нас сегодня не про BPMS будет. Наверное, про BBMS возможно будет в следующий раз. Гузель, специалист по внедрению узнать, как правильно моделировать интеграции. Супер. Сергей, программист один. Узнать про документирование интеграции. Угу. Так. А, Юрий аналитик, функциональный архитектор. Интересно применение нотации BPM для моделирования интеграции. Угу. Супер, коллеги. Да, пожалуйста, пишите, я, если что, потом попозже дочитаю.
А кратенько, коллеги, об Otс расскажу, что такое OTUS, м зачем она нам сейчас необходима в жизни. А OTOS создаёт авторские онлайн-курсы, которые подходят специалистам с различным уровнем подготовки от джуниоров до синьоров и лидов. Независимо от вашего опыта и знаний, вы сможете найти всегда подходящую программу, которая поможет вам улучшить навыки. Ус есть образовательная лицензия. Вы сможете получить официальное удостоверение и повышение квалификации, диплом о пропреподготовке, а также сделать налоговый вычет по окончанию, соответственно, курса, который вы выберете. курсов великое множество, более 130 в настоящее время от программирования до data science, gdf управления и всё прочее. Курсы регулярно обновляются, выходят новые. В общем, тема такая довольно прокачанная.
Всё, коллеги, реклама закончилась. Давайте уже будем приступать к нашей теме, а я дочитаю представление коллег. А так, аналитик повышение квалификации. Цель: Василий, ведущий аналитик документирования, интеграции БПМН. Интересно. Марина, ведущий аналитик на проектах внедрения. Супер. Нотацию применяю, но самоучка. Хочу узнать новое для себя. Супер, коллега. Коллеги, я, в принципе, так и ожидал, что коллеги хотят познакомиться, узнать и расширить свои знания. И многие, я вижу, уже являются так или иначе экспертами, относительными в этой области. Супер.
Давайте начнём. посмотрим маршрут нашего вебинара. Мы с вами, а, посмотрим сначала способы отображение интеграции, то есть вообще какие бывают интеграции для возможности их моделирования, в каких нотациях можно моделировать. Дальше мы посмотрим уровни отображения интеграции именно в BPMAN. И дальше у меня будет практика. Я на практике разберу один из примеров того, как можно смоделировать интеграцию BPMN. Заодно м я дополнительно буду ещё рассказывать по а практическим приёмам аэ качественного моделирования в BPMN. Дальше мы подведём итоги по интеграции MBPM, и я немножко расскажу про курс Архитектор 1С, потому что наш вебинар идёт в рамках, а, запуска следующего потока курса Архитектор Гатинес.
Так, а Л Алёна спрашивает: "Подскажите, а запись будет на почту?" Да, Алён, конечно, будет запись. И плюс вы можете подписаться на Otus в ВК, там много выходят, ну, регулярные открытые уроки. Не только вот этот сегодняшний, но и много других, мне кажется, очень интересных. Я регулярно сам смотрю, коллеги, и вам рекомендую абсолютно бесплатно. Я где такое может быть в наши дни?
Целью сегодняшнего вебинара, коллеги, познакомиться с типами диаграмм для отображения интеграции. То есть нам надо понимать, какие возможности у нас вообще есть для аа рисования, моделирования интеграции. Дальше, а разобраться в уровнях отображения интеграции BPMN. Возможно, вы даже о них раньше не слышали. Довольно-таки, ээ, редкая, уникальная штука. И третье, уметь на практике, а моделировать интеграцию с помощью BPM, потому что это, мне кажется, хорошее умение, которое сильно вас, а, во многом, как аналитика, как функционального или технического архитектора продвинет дальше.
Давайте начнём со способов отображения интеграции. И у меня, коллеги, вопрос по теме первый к вам. А напишите, пожалуйста, какой инструмент инотацию вы используете для моделирования интеграции. Вот такой вот вопрос. То есть, как вообще вы рисуете интеграции? Может, в Пейн их рисуете? Э, может быть, следуете какой-то из нотаций, то как какой? Ну, и с каким инструментом вы это делаете? Напишите, пожалуйста.
Так, вижу. Рустам написал: "Draw i bpm man". Здорово, Рустам. Ну, значит, да, BPM, значит, вам сегодня близкая тема. Так, Марина пишет: "Дро iioо. Марин, напишите, пожалуйста, а в нотации какой как вы именно рисуете эти интеграции?" Юрий, собственно, нотация на базе EPC. Супер. Очень интересно. Ага, с элементами SD UMIL. Ага, Юрий, я тоже про неё немножко сегодня буду дальше говорить. Евгений DFD визё. Отлично. Марина в БПмен. Всё супер. Я, честно говоря, даже не думал, что кто-то из коллег в BPMмен интеграции рисует, потому что всё-таки большинство из моей практики я встречал больше в EPS, а sequнс диаграммы, ну и скорее там уже какие-нибудь архитектурные инструменты в виде Архимейта либо C4. Дальше тоже про это проговорю. А Visзио вижу, да, несколько коллег рисуют Vision. Ну, видимо, какую-то произвольную, не закрепляясь за аннотации, да, это тоже реально, и это тоже мы часто делаем. Супер. Ну, никто не поставил минусик. Все, я так понимаю, так или иначе в чём-то как-то рисуют. Это здорово.
А давайте рассмотрим вообще, а какие вообще у нас есть возможности, в каких нотациях мы можем моделировать интеграции. Я вот вывел наиболее, как мне кажется, распространёнными распространённые. Начнём с C4. C4 подходит для высокоровнего описания интеграции между системами и сервисами. И он хорошо показывает участников интеграции границы, связи, аа интерфейсы и место интеграции в общей архитектуре. То есть довольно серьёзная нотация. У нас неоднократно, на самом деле, были открыты уроки по C4. Если захотите, можете их найти. А C4, её аналог, даже можно сказать, которую можно сильно поставить в противовес, это Ахмейд. Тоже серьёзная, мощная нотация, многослойная, позволяет реально описать любую интеграцию. Основной фокус делается все четыре на кто с кем интегрируется и через что. То есть, если нам требуется прямо это детально показать, то мы выбираем с вами C4.
Следующая нотация - это нотация из разряда UML sequence sequence диаграммы. Они Мы дальше посмотрим, коллеги, как они выглядят. Эти sequнсдиаграммы нужны для того, чтобы показать по шагам какой-то сценарий, какой-то короткий сценарий. взаимодействия систем. А EPS тоже вот коллеги уже говорили, что тоже частично используют, а используется для интеграции и может отвечать на вопрос, какой бизнес процесс происходит, какие события его запускают и какие функции. То есть, а-а, здесь фокус у нас будет делаться на как раз вот это вот, а, последовательность события, действия условий. Кто, возможно, знаком с EPS об этом знает. То есть, а, вполне можно рисовать интеграцию. И последний вариант - это BPMAN, когда нам нужно писать бизнес-процесс, а, в целом, а, и ещё с учётом интеграции. У нас есть различные участники, например, люди, системы и, возможно, много условий и втлений. Если мы возьмём, мм, а как пример это UML sequнс для коротких маленьких сценариев очень неплохо-таки подходит, но когда требуется что-то усложнять, ветвица с разными условияем, здесь UML sequence диаграммы точно не стоит использовать. стоит рассмотреть, например, BPM как раз для этих целей. Соответственно, фокус здесь идёт на то, почему и в каком процессе у нас происходят интеграции. Именно на этот вопрос мы точно сможем за счёт BPмна ответить. А Юрий пишет: "Из UML можно ещё использовать диаграмму взаимодействия". Да, согласен. Это как дополнение к seквенс диаграммам. Ну, абсолютно с вами согласен.
Аа, поехали. Дальше давайте посмотрим примеры вот этих четырёх вариаций отображения C4. Соответственно, мы здесь показываем архитектуру интеграции на высоком уровне. И здесь можем объяснить, какие системы у нас с чем взаимодействуют. А все C4 довольно неплохо понимается бизнесом и архитекторами. Соответственно, вполне совместно можно проводить, а, обсуждение, допустим, по тому, как как какой нам по необходимо за закупить, возможно, использовать, как оно будет соединяться, по каким портам. Аэ, в общем-то, довольно-таки неплохо можно рисовать. Такие схемы называются архитектурные или схемы, м, системной архитектуры. А вот довольно детально можно рисовать, но, как вы видите, здесь у нас мы можем показать хронологию взаимодействия, но не можем показать условий и ветвлений, а иногда это очень нужно. Вот явный минус здесь с четыре выпадания, что мы не можем какие-то условия здесь отражать. Если нам не требуется отражать условия, мы нечто высокоуровнево показываем, то, конечно же, она прекрасно подходит, и я её очень вам рекомендую, когда мы отображаем в целом всю нашу архитектуру интеграции.
До этого дальше это sequнс диаграммы, а, одна из нотаций UML. Соответственно, здесь мы показываем, кто с кем и в каком порядке взаимодействуют системы без каких-то длинных описаний, без додумываний. Соответственно, а если у вас что-то короткое, что-то, какой-то маленький, небольшой сценарий взаимодействия вам надо показать, я рекомендую использовать именно sequence диаграмму, именно её как номер один для выбора того, какой нотации вам стоит э дело. показать. То есть номер один для использования в чём-то простом - это, конечно же, SEнсдиаграмма. А её можно рисовать в различных редакторах, начиная от визио, но более эффективный, как мне кажется, современный сейчас способ это использовать plant plant Umail или Mermade. А, то есть это рисование с помощью кода, то есть специальным простым кодом мы готовим э такие текст таких диаграмм, в том числе его можно подготовить с помощью искусства интеллекта в чат GPT, например, или в Gemy загнать базовые условия, он вам легко её нарисует. Ему она будет искусственному интеллекту обычно очень легко даётся аа рендеринг такой диаграммы. То есть здесь мы видим, у нас есть некие пользователи этой системы и есть мы можем их и есть поэтапно показана аэ хронология взаимодействия с этими системами. Возможно в Sequнс добавляйте условия, так называемые Alt альтернативные ходы, но здесь рекомендация простая. Максимум, если у вас одно условие будет ещё о'кей его добавить в эту L sequнс диаграмму. Если условий более одного, то, коллеги, 100% я не рекомендую такие диаграммы рисовать. Часто попадал на то у коллег, что начинают десятки ветвлений показывать с помощью вот этой sequнс диаграммы. И, к сожалению, вместо понятной лёгкой схемы, это выходит в нечитабельную схему. Соответственно, запомните, ноль или одно условие, о'кей. И что-то небольшое простое, например, шагов там на 10. Тут 1 2 у нас 3 4 5 6 7. О'кей. То есть 10 15 о'кей, но не более. А и чёткая хронология, когда понятно, тогда её рисуем.
Следующий вариант - это EPC. Как она выглядит? Соответственно, у нас м EPC а требуется чётко показывать аа порядок а условий после функции. И здесь у нас, а обычно рисуется она вертикально, то есть начало сверху, и мы спускаемся вниз. А когда уместен, его стоит брать, а если вам нужно согласовать интеграцию с бизнесом? А интеграция не сильно большая, но в то же время не такая маленькая, как, допустим, ну, не точно не на 10 шагов. Здесь можно и 30, и 40 шагов показать. А когда вам надо нарисовать end to end процесс, то есть от начала его до конца, ни в коем случае PC не рисуются. там кусочно её рисуют в целом от начала до конца. Важно в ней обязательно разобрать её на системы, а выделить условия, точки контроля и их описать. Важно отделять обязательно VPS, как я сказал, события от функций. То есть, ээ, такая диаграмма вполне читабельная, но к ней нужно приноровиться, то есть вот к этому вертикальному виду. Так, когда EPS не подходит? А она хуже подходит, если нужно показать точный порядок каких-то технических сообщений, какие-то указать, допустим, требуются какие-то конкретные IP, а отразить взаимодействие сервисов. Мм, для этого лучше либо поэлементно каждый сценарий описывать через SEC диаграмму или опять же использовать дальше BPMAN.
В ГПМН мы сейчас придём. А коллега Актос пишет: "Похож на бизнес-процесс в 1С. Да, есть такое, но всё-таки ИС более серьёзней штука, чем бизнес-процессы". Бизнес-процессы 1С - это скорее диаграммы Вирта или Вюэле - это диаграммы состояний. Я про них специально не говорил, потому что, ну, как мне кажется, диаграммами состояния рисовать интеграции, в принципе, можно, но что-то, опять же, короткое уровня sequence диаграмм, но опять же, когда есть sequence диаграмма, лучше тогда вот этой sequence диаграммой их рисовать. А, Юрий мне поправляет не состояние, не состояние, а активности. Да, Юрий, активности, но, по-моему, её ещё и состояние называют, да? Диаграмма активности. По-моему, её ещё и состояние диаграммы называют. Это всё диаграммы Вирта. Это всё развитие блоксхем диаграммы Вирта.
Так, идём дальше. BPмен, соответственно, BPM интеграции могут выглядеть, а, нужны, когда нужно описать бизнес-процесс в целом от начала до конца, то есть end to end. У нас есть ярко выделенные участники. Это люди, системы. У нас есть возможные условия, витвлении. Нам важна логика процесса и оркестрация. Здесь мы фокус, соответственно, делаем, почему и в каком процессе у нас происходит интеграция. В примере у меня здесь используются два пула подпроцессов. Например, это работа с чеками 1С в 1С бухгалтерии и работа онлайн кас. Здесь у меня отражается процесс формирования чеков. Есть роль продавец. А роли можно задавать через а горизонтальные дорожки. Я сегодня и в примере тоже. Я не буду горизонтальные дорожки использовать. Я их буду использовать с помощью вот таких вот обозначений, а, ролей сверху. Если, соответственно, ваш редактор это позволяет, можно такие роли задавать. А, либо можно задавать их цветом выделять, либо разделять по дорожкам. Ну, для экономии места я решил не использовать дорожки. Это допустимо в рамках нотации BPMN. Соответственно, у нас есть здесь люди и есть, а, автоматизированные какие-то процессы, которые у нас осуществляют так называемые интеграционные процессы. То есть начинает взаимодействие, допустим, бухгалтерия взаимодействует с кассами. И здесь происходит, допустим, в онлайнкас какая-то фискальная обработка и автоматическая отправка в ФНС. Ну, ФНС у нас нечто внешнее, никак нами неконтролируемое. Вот мы в этот ФНС отправляем аа чеки. Соответственно, по слеотправке мы от ФНС получаем подтверждение чеков в опять же в нашу электронную кассу бухгалтери и так далее. Пример это пример вот примерно так можно описывать один один из вариантов интеграции. Ну дальше мы посмотрим уже с учётом уровня интеграции.
Так, сейчас я посмотрю. А Михаил пишет SDLр, а graphical presentation. Вот Михаил, если да, расшифруете, что это такое, что вы имеете в виду, и буду благодарен. Я не знаю, что такое SDLГР. Да, ну, ну звучит красиво. А графический SDL? Ага, получше. Так, и что это такое? Михаил графический СДЛ. Что это? Кто это? С чем его идят? Скиньте ссылку, пример, посмотрим. О'кей, коллеги, да, я видел, что многие коллеги из вас написали, что с БПМН работали. Поставьте, пожалуйста, коллеги, плюсы, два плюсика, кто работает, работал с BPMN. Плюсик, если вы вообще знакомы с нотацией BPM, и минусик, если вообще ещё пока не знаете про неё. Чтобы я, коллеги, понимал, стоит ли мне больше акцент делать сейчас на то, что это такое. Так, вижу, что большинство коллег знают, что это такое. Так, ну, есть пара коллег незнакомы. Угу. Так, ну, большинство, да, знают. Супер, коллеги, да, я поэтому не сильно буду сейчас задерживаться на базовых моментах. На них чуть-чуть акцент сделаю и мы пойдём дальше. А так Михаил пишет: "Диаграммы SDL specification and description language использует собственную стандартизированную нотацию, определяемую рекомендациями какими-то. Это язык графического моделирования, который базируется на концепции взаимодействия конечных автоматов. Возможно, я работал с ней Михаил, но вот так вот с ходу не могу вспомнить. Возможно, сталкивался и я с ней, ну вот так в лоб ничего не могу сказать про неё. Напишите, Михаил, если вы работали вот с этой SDL, м, напишите ваше мнение, для каких интеграций можно её использовать и как её можно использовать. Может быть, даже маленький пример того, как эти SDL можно использовать. Будет здорово. Я, может быть, следующий раз к следующему открытому уроку дополню а свою свой вебинар. А пишет Михаил, что весь телеком на них сидит. Ну, супер, супер, супер. Может быть, да, скинете пример, как это выглядит. Здорово.
Так, BPM, что это такое-то? кратенько. Это нотация, которая довольно является молодой, вышла в 2004 году. Это была её первая версия. Вторая версия вышла буквально 10 лет спустя, в 2011 году. А расшифровывался как бизнес process model and notation, то есть нотация для представления на языке бизнеса. Специально она создавалась для того, чтобы, аэ, улучшить взаимодействие, э, ИТ с бизнесом. Бизнес довольно неплохо её читает, понимает, поэтому она довольно сильно получила своего распространения. А есть так называемый термин ещё BPMS - это системы моделирования бизнес-процессов. Что это такое? Это как раз инструменты, внутри которых вы можете нарисовать модель. И дальше эти модели у вас будут делать какие-то функциональные действия осуществлять программные. То есть, например, это яркие инструменты, это такие как Бизаги, Комунда или наша российская Элма как раз обладают таким функционалом. Основные плюсы нотации - это возможность разделения исполнителей, например, в виде дорожек. Вот у меня справа на примере видно раз дорожка, два дорожка, то есть сотрудник КЦ, менеджер КЦ. А, либо можно разделять отдельно, подписывая ролей, если ваш редактор этим обладает. Ну либо можно, а, выделять цветом, но обязательно делать дополнительно легенду, где вы подпишите, что значит какой цвет. Есть возможность гибкой развилки процессов. Причём развилки процессов имеют довольно много разных типов. А, то есть есть шлюзы разделительные, есть шлюзы параллельные, есть шлюзы всякие комплексные и другие довольно-таки непростые есть шлюзы. Плюс, мм, есть события, события входные, события, в которых идёт завершение, и каждое событие обладает тоже своим определённым набором типов. Мы сейчас в это не будем углубляться, это кратко. То есть с виду кажется она нотация - это очень простой, но в то же время она, конечно же, имеет за счёт вот вот этих свойств элементов довольно сильно её можно усложнить. Я лично противник слильного усложнения, потому что если сильно усложнить, то бизнес перестанет такие схемы читать и понимать, а мы рисуем, моделируем их ради того, чтобы наш бизнес мог с этим полноценно тоже работать и согласовывать наши наши будущие реализации, которую мы отразили на схеме.
О'кей. Какие инструменты BPMN бывают? Бывают инструменты. Популярный онлайнконструктор движок Demo BPMN io. Ну либо BPMNO. Там непосредственно вы можете познакомиться с библиотеками, open source библиотеками, которые можно куда-либо встраивать, допустим, если вы хотите создать свому свою BPMS-систему. Есть Комун. Коммунда один из лидеров сейчас, э-э, BPMМM BPM систем. И на базе Комунды как раз сделан тот же BPMNO движок. Кому можно установить на компьютер базовые базовую программу, но, к сожалению, базовая программа она очень упрощённая, то есть очень простая. Вот Комунду обычно все используют скорее как движок, в рамках которого что-либо потом реализуют. Draw IO никто не отнимал. Там, конечно же, есть поддержка у нас а нотации BPMN. А, ну сейчас он называется app Diagramsnet. Второе название у Draw. Iio. Есть ещё старый инструмент Безаги. Безаги, конечно, уже сильно устарел и в последние годы уже мало кто им пользуется. Многие скорее по привычке. Он устанавливается, и вы с ним можете работать. Единственно, требуется регистрация. Регистрация требуется. А наши российские инструменты - это популярнейший инструмент Шторм BPM. В России он наиболее популярен, наиболее известен. Известен он и не только как сам инструмент, но ещё и личностью, которая его представляет. А личность - это Денис Котов. Денис Котов, можно сказать, джедай BPмена у нас в России последние 10 лет. Множество от него курсов в Ютубе. Можете послушать, зайти через сайтм BPMAN. Ну и он проводит различные конференции тоже вокруг BPмна. Вот. То есть ему большой поклон и уважение, конечно же, что именно он развивает VPM в России больше всех. Вот есть инструмент, который представляю я, называется VBPM. А это упрощённый вариант шторм BPмна, но тоже имеющий, в принципе, те же функции, что и шторм БПНА, более простые. Я вам буду сегодня именно в нём демонстрировать работу. Дальше я вам дам бонусную ссылку приглашения, на которую вы можете зайти и, а, его начать использовать. Минус шторм BPMN - это то, что он подписочный. То есть в базовой версии бесплатной у вас ограничены сильно функционал. Например, в базовой версии Шторм БПМНА, к сожалению, вам недоступна возможность как раз рисовать роли. То есть вы не можете назначать роли на элементах, на задачах, и вам нужно для этого создавать либо дорожки, либо выделять цветом. Ну и, конечно, рекламы очень много. просящую подписку. А подписка довольно, как мне кажется, дорогая. Ну вот в моём варианте здесь пока у меня нет никакой рекламы, ничего нет. Более в этом плане, как мне кажется, интереснее. Вот. Но я ни в коем случае не пытаюсь конкурировать со Шторм BPменом. Так. И есть ещё, да, вот Андрей меня поправляет. B Studio. Да, бизнес Studio тоже мощная система, много по ней, кстати, несколько книг даже написано. Тоже отличная система, да, наверное, просто я её что-то забыл. Можно было бы его рядом с Безаги поставить. А, вполне отличная штука, да, Бизнес Studio, конечно, абсолютно согласен. Возможно, ещё какие-то инструменты, коллеги, есть, потому что, а, их много, да. Поэтому вот, Евгений, отвечая на ваш вопрос, какой самый инструмент популярны в России? Я однозначно считаю никакие не бизнесдио, никакие не Бизаги сейчас, а строго Шторм BPM. Вот Михаил мне ещё Spark X. Ага, не слышал такой. У Михаила, да, какие-то набор неизвестных штук. А сила Union, да, вот Сила Union, да, есть тоже такой инструмент. Это для корпоративного использования. Полностью платные, никакого бесплатной возможности нет. Закрытые, платные, внутри сильно ограничены. Никаких вам искусственных интеллектов, ничего. Вот. Ну вот Михаил расшифровывать. Spar X - это пишет Spar X, архитект. Не слышал, не работал. Может, когда-нибудь увижу. Вот так.
Идём, коллеги, дальше. Думаю, по инструментам разобрались. То есть инструментов хватает, как бесплатных, так полубесплатных. В принципе, можно для себя подобрать удобно. Не забываем также ещё Microsoft VO. Конечно же, в нём тоже многие рисуют, но я настоятельно не рекомендую использовать такие инструменты, как Visio даже тот же Draw IO, потому что они не специализированы под этот, под нотацию. И, ну, если вы освоите хорошо вот инструменты под наточенные под нотацию, вам гораздо проще и быстрее будет рисовать, нежели каком-нибудь Visual или Draw io.
Так. О'кей. Кратко по условным обозначениям, коллеги, пробежимся. У нас есть вход. Как правило, его обозначают зелёным цветом. Аа выход, ну, выход обозначают красным цветом. Есть ещё промежуточные действия, их обозначают жёлтым цветом. Вот. Либо там линия с пунктирной линией в кружочке. Вот. Аа выход обычно всегда жирно выделенная линия должна быть. Не обязательно даже красная, но уже я ввожу это как стандарт, что зелёный старт, выход красный. Стоит обозначать, если даже он у вас по умолчанию в редакторе не обозначается. А процедура шаг, где непосредственно выполняется действие, которое вы хотите выполнить. Обязательно должно отвечать на вопрос, что сделать, рассчитать, а создать. А, запустить и так далее. Процедура действия должно быть простое, короткое, лёгкое. Если вам нужна какая-то детализация, то, пожалуйста, отражайте её и в виде дополнительной текстовой аннотации. Не стоит перегружать процедуры, шаги. Также есть, как я сказал, шлюзы. Шлюзов пять или шесть. То есть вот я их постоянно, а, классических пять шлюзов. Самые популярные, распространённые - это два шлюза. Шлюз или, который разделяет у вас потоки на несколько альтернативных маршрутов и шлюз и параллельный, который используется для распараллеливания маршрутов. И в дальнейшем вы помощью него можете опять же их обратно собрать, синхронизировать эти потоки. Всё это рисуется на едином пуле. Пул может разделяться по дорожкам. Может, а может он не разделяться, если, допустим, цитировать того же Дениса Котова, он абсолютно противник. А разделение на дорожки, пулы. То есть ни в коем случае он всегда
рекомендует не использовать дорожки, а использовать роли. Но опять же парадокс, у него роли есть только в платной подписке. То есть, понимаете, чтобы их использовать, значит, надо купить у него подписку. Либо как аналог, который мы используем. Бывает, если нет платной подписки у Шторма, то использовать выделение цветом тоже о'кей, но тогда сбоку легенду делаете вот этих ролей.
Так, э, всё это соединяется стрелками, потоками управления. Есть ещё дополнительные хранилище как раз данных информационной системы, которым мы показываем чтение и запись. Их как раз мы с вами далее будем использовать для работы с интеграциями. А чуть позже я покажу, как это будет делаться.
Так, Андрей поправляет. Вход-то не вход, а начальное событие. Да, Андрей, вход. Начальный триггер, начальное событие. Да. Андрей меня поправляет. Они обязательно зелёная. Да, Андрей, абсолютно с вами согласен. В классическом BPMN iO в Комунде оно не зелёное. Оно оно не зелёное, да, но я рекомендую всем выделять зелёный цвет. Андрей, также сделаны сейчас и шторм БПмни. Раньше не было зелёным. Вот так. И в моём тоже редакторе тоже я выделяю зелёну с, чтобы издалека было видно. А я думаю, это можно как стандарт в будущем закрепить. Вот. А завершающий триггер, соответственно, красным с трегом, э, красным цветом. Андрей, так. А нестрогая или множественная? Э, так вопрос задаёт. Шлюз или это исключающий шлюз, который разделяет на потоке?
Так, коллеги, идём дальше. Аа для Я сегодня буду показывать на своём инструменте. Вы, если захотите повторить, можете использовать абсолютно любые инструменты. Хоть Сила Union, хоть Do, хоть Vision. Бонусно к данному курсу я вам скину сейчас ссылочку, по которой вы можете зарегистрироваться. Сам этот продукт, он в лоб недоступен. В него нельзя в лоб взять, зайти и зарегистрироваться. Только по отдельному приглашению. Ссылку приглашения я как бонус вам сейчас скину. Плюс есть QR-код. Можете считать этот QR-код. Сразу говорю, что она действует, время на регистрацию действует, по-моему, месяц у меня настроено и плюс там лимит ограниченный. Я ограничил, по-моему, лимит 30трицатью или 40 регистрациями. То есть кто, как говорится, успел, тот успел. Вот. А, то есть, кому интересно, могут зайти, подключиться и бесплатно начать работать без с теми же фишками, чтом BP. Вот это сама платформа позволяет моделировать BPMN в полном объёме. И давайте, коллеги, уже придём, пойдём дальше к интеграции.
А важный момент - это разделение на уровни интеграции BPM. Какие уровни существуют? Их существует четыре. Первый уровень, который считается верхнеуровневым, а это уровень концептуальный. Он показывает ландшафт системы в целом. То есть мы на нём отражаем, а, в целом аа верхнеуровневую систему того, с чем она у нас, вернее, процесс, верхнеуровневый процесс и с какими системами внешними, например, он у нас взаимодействует. Здесь у меня отображено, что Zub интегрирован с СФР и с банками. Ну, соответственно, у вас может быть больше отображено. Здесь нет никакой детализации, то есть внутренние шаги процесса я не раскрываю. Здесь нет никаких витвлений, условий. Здесь есть только вот верхнеуровневые подпроцессы. Плюсик в задаче, в шаге, это значит подпроцесс, но я его по сути не расшифровываю. Если есть потребность внутри, конечно, я могу его в дальнейшем расшифровать. Это уже будет другой уровень, то есть так называемый концептуальный уровень, когда у нас есть общая информация, мы хотим в целом показать, с какими системами возможными у нас, э, интегрируются данные данная система. Так вот, можем мы отразить плюс показать хронологию, возможную, последовательность этих интеграций.
Следующий уровень - это межпроцессный уровень. То есть это уже уровень, когда мы показываем, а, взаимодействие с внешними системами опять же также, как концептальным, через внешние пулы. То есть у нас вот опять же есть вот этот пул с СФР. А, но здесь у нас уже появляется особенность. Мы здесь уже можем выделять конкретных исполнителей в виде, например, ролей либо дорожек горизонтальных, то есть дробить. У нас здесь известны конкретные исполнители, если они есть. Плюс мы можем процессы делить на системы, ну, в том числе внутри дорожек тоже указывать отдельные, а, отдельные системы. А здесь рекомендуется не отражать шлюзы условий, а показывать только так называемый Hэy Pass, то есть успешный путь завершения. То есть здесь мы опять же тоже условий не показываем, но зато у нас уже есть вот эти самые роли, то есть более детализированный э такой процесс.
Так, э идём дальше. Третий уровень - это уже уровень процессный. Здесь у нас все действия происходят внутри, как правило, одного процесса без выделения внешних участников пулов. То есть у нас нет дополнительных пулов, как вот это было ранее. Вот здесь вот выделенный пустой пул, с кем мы взаимодействуем и от кого мы не знаем, какая может быть обратная связь. Здесь у нас мы уже не выделяем внешних пулов. А действия у нас уже, конечно же, здесь также привязаны уже к конкретным исполнителям, дорожкам, ролям. У нас здесь появляются уже условия процесса, которые могут быть отражены в виде разделительных шлюзов. То есть, если мы здесь пойдём по процессу, то у нас что у нас здесь процесс? Оформление отпуска в 1С кабинет сотрудника. То есть у нас сначала сотрудник открывает раздел отпуска, проверяет остаток дней, создаёт заявление на отпуск. Всё это он делает в личном кабинете. Плюс, обратите внимание, как мы понимаем, что это личный кабинет с помощью отображения вот такого артефакта, а, data storage, а, кабинет сотрудника. То есть, соответственно, когда он к нему обращается, мы стрелочкой показываем, что идёт к нему обращение. А такую штуку можно показать, допустим, на самом деле, нарисовав отдельную дорожку, но можно и упрощать, показывать в виде вот такого вот отдельного артефакта Data Storage. Именно с ней впоследствии вот этот сотрудник у нас и взаимодействует. Я не показываю стрелочки по несколько раз, ну и обычно коллегам, студентам рекомендую тоже не рисовать 10 стрелок. Одна первая стрелка говорит о том, что все последующие у нас также обращаются, взаимодействуют с этим самым, в данном случае 1Скабинет сотрудника. На каком-то из этапов у нас происходит а отправка на согласование. То есть где-то сотрудник создал заявление на отпуск и где-то автоматически внутри, э, кабинет сотрудника происходит отправка системой на согласование. Дальше у нас руководитель согласовывает это заявление, и результат его согласования у нас разделяется уже появляется условия. То есть когда если заявление у нас согласовано, то мы идём по направлению да. Если нет, то у нас фиксируется отказ аа в нашем 1Скабинет сотрудника и сотрудник получает уведомление об отказе. На этом у нас процесс заканчивается. В BPMN можно завершать много раз процессы, а также, кстати, и стартовать. То есть, э, стартовые триггеры тоже их может быть много. Их можно в разное время их можно параллелить по-разному. Много запусков можно делать. Если у нас, да, мы проверяем корректность заявки. И обратите внимание, у нас здесь проверка корректности уже идёт в системе зуб. Кадровый работник у нас проверяет через зуб аа заявку. Далее у нас он оформляет отпуск либо, э, оформляет если заявка корректна, либо если она некорректна, то возвращает с определённым отказом. Передаёт статус в кабинет, в личный кабинет. и так далее. Соответственно, итог у нас будет, что отпуск оформлен. Вот пример процесс уровня. Вот, на самом деле, да, схему можно улучшать, а какие-то моменты даже более детализировать, либо наоборот даже что-то лишнее убрать. Вот. Но тем не менее, думаю, понятно, что у нас уже нет здесь внешних пулов.
Следующий уровень - это технический, он же последний BP. Здесь отражается всё тоже, что и в уровне три процессном. Аа, но появляется уже мм этот уровень уже нужен прежде всего для, как правило, обработки исключений при обмене. Он детализирует логику поведения системы, например, при тайм-аутах каких-то ошибок, каких-то граничных событий. И, например, здесь мы можем детализировать вот на примере отказ с помощью вот таких условий. То есть у нас есть функция уже явно выделенная, это проверкан сотрудника в зуб. А происходит её вызов, вызов проверки функциин. И здесь у нас м а три варианта развития событий. То есть при вызове проверки ННН у нас может быть ошибка пятисотая, и мы уходим вот здесь вот в этот шлюз, а в данном случае разделительный, который объединяет у нас, так как на вход принимает данные. А, либо у нас может быть тайм-аут, например, ответа более 30 секунд. И когда мы вызвали IP, соответственно, тайм-аут сработал, мы тоже уходим в этот в это направление. Безусловно, уходим и уже по хэппи пасу не идём. Если у нас всё хорошо, то есть не произошло ошибки, не произошло тайм-аута больше 30 секунд, то мы идём вот сюда. И по сути у нас завершается процесс. э внесением статуса, что у нас всё, сотрудник проверен. Соответственно, если нет, то у нас, допустим, здесь подключается новый участник уже бухгалтер, который проверяет н вручную через сайт. Ну, здесь я дополнительно указываю, что он обращается к сайт на nalog.ru. И опять же дальше после его успешной фиксации, проверки у нас статус опять же тоже поменяется на проверенный.
Так, Евгений, а четвёртый уровень, а четыре уровня - это четыре разные диаграммы или всё на одной диаграмме? Как в итоге это выглядит? Мм, я рекомендую разделять разделять эти диаграммы плюс, а нельзя сказать, что вот эти диаграммы - это ой, эти уровни - это догма. То есть технически вы рисуете только так. На самом деле можно и группировать, допустим, третий, который у нас был процессный, его можно группировать и с техническим. А концептуальный, например, тоже можно группировать, а с межпроцессным. Ну, вернее, вы даже сами видели, что тот же межпроцессный - это развитие концептуального, процессный - это развитие межпроцессного. То есть группировки можно делать на плюс один уровень. вполне это допустимо. То есть здесь нет такого явного зависимости, если мы возьмём классический Архимейд, где мы не можем из одного слоя в другой прыгать. Вот здесь мы можем, да, между ними играться, их между собой комбинировать, но опять же аккуратно, не нужно пытаться захватывать сразу все уровни. Можно для этого вы уже создаёте отдельные схемы. То есть можете вначале сделать схему концептуальную, дальше, допустим, схему межпроцессную тире процессную. У вас может быть это быть одной схемой. И если вдруг есть потребность в отражении отдельных каких-то а функций интеграции, вы их можете включить в виде подпроцессы. Ну вот подпроцесс я вот здесь показывал, как обозначается в виде плюсика. и внутри него расшифровать вот эту вот логику, либо вынести опять же в отдельную схему. Это тоже вполне нормально, как отдельная будет схема, отдельный сценарий этого процесса.
Так. А, так, Андрей, это называется ограниченные события, да? Ага. А, Андрей, Андрей пишет: "Архитектура бизнес-процессов позволяет разделить эти уровни диаграмм". Да, да, всё верно. Юрий, было бы замечательно, если бы на модели можно было указать конкретные объекты конфигурации 1С, с которыми взаимодействуют пользователи и их которые инициируются обмен с другой системы. Ну, видите, в чём проблема, Юрий? Если мы берём классические нотации BPM, EPS, мы здесь не можем что-то лишнее сюда добавлять. Здесь строгое количество элементов, оно строго ограничено. Даже вот эта вот картинка, по сути, она добавлена мной, ну, немножко с нарушением стандарта, но немножко, потому что всё-таки вот, если посмотреть за неё, здесь у меня просматривается классический элемент data storage. Вот. Но если вот сейчас бы этот вебинар смотрел бы Денис Котов и был бы в комментаторах, он бы сразу сказал: "Что за ерунда? Вот он бы, наверное, со мной не согласился. Вот. Хотя он раньше бы не согласился и цветом выделять, а сейчас уже сам выделяет цветом старты и завершение. Вот. Но, соответственно, не должно быть лишних каких-то элементов вне нотации. Эта нотация запрещает строго. Поэтому вырви глаз выглядит, когда вы, допустим, рисуете видео или в drive. И когда у вас взят э набор элементов из BPмена, и вы вдруг начинаете вставлять какие-то левые сегменты, левые элементы. Это вырви глаз, смотрится. И так не стоит, конечно, никогда делать. Если вы рисуете в нотации BPM, допустим, Draw io, то строго используйте элементы, которые у вас есть. Соответственно, никаких объектов метаданных адсовских здесь не должно быть. Это будет сильным нарушением. стандарта BPмена цветами выделять, пожалуйста, вот, но ни в коем случае не вставлять какие-то свои элементы.
Так, Андрей пишет: "Если отражать объекты их связи, то это нотация UML. Да, вполне". Как какую-то из нотаций UML можно использовать? Ну, а BPMAN - это поток задач. Ну, я бы сказал, BPM - это всё-таки функциональная схема, которая отображает процесс end to end. У нас есть старт, есть финиш. И причём стартов может быть много, финишей тоже может быть много. А Юрий пишет: "Поэтому я и пришёл к необходимости создания своей дотации". Ага, вот это интересно. В ней как раз указываются объекты конфигурации и связи между ними на отдельной дорожке, соответствующей системе 1С. А, ну здесь у меня, Юрий, к вам рекомендация всё-таки не пытаться создавать, может быть, свою нотацию, а, может быть, каким-то образом адаптироваться к текущим нотациям, потому что вашу нотацию собственную может м как это люди не сильно принять. То есть особенно на корпсегменте, когда вы выходите, начинаете какую-то от себятину показывать, ну, не все её воспримут. Например, я точно буду Юрий, скорее всего, противник какой-то своей кастомной нотации. Вот таких ребят много, в том числе и тот же Денис Котов. Андрей, на дорожках можно запустить отдельный функциональный модуль. Да, Андрей, совершенно верно. Да, вы можете выделять дорожки и каким-то образом это всё выделять. Ну, сейчас мы всё это на практике посмотрим, попрактикуемся, нарисуем схемочку и ещё пройдемся по вопросам. Поэтому, а, свои нокации не знаю. Мне кажется, в наши дни и так достаточно разных нотаций, только стоит их правильно применять.
Так, давайте практика. Что мы с вами будем делать? Вы можете повторять за мной, можете потом отдельно это всё попробовать. Вы можете открыть редактор. Ну, я открою сейчас BPMAN. Вам тоже ссылочку я скинул. QR-кодик есть, можете тоже использовать и зайти, зарегистрироваться бесплатно, без SMS и регистраций. Ну, регистрация минимальная есть имя, фамилию и email нужно будет ввести с логином, паролем вашим. Больше ничего. А мы смоделируем с вами сейчас интеграцию бесшовного обмена 1S с 1SDO в рамках процесса подписания приказа в нотации BPMN. Вот такую вот мы микрозадачу ставим. Я попробую сделать с использованием уровня три процессного, так, потому что, ну, другие уровни расовывать уже времени просто не хватит. Давайте начнём, коллеги. Так, заодно буду пройдусь по как бы концептуальным моментам BPмна. Зашёл в продукт, нажимаю кнопочку создать новую диаграмму в правом верхнем углу и начинаю моделировать. Так, с чего мы начинаем любое моделирование, это, конечно же, с Так, я давайте уменьшу пространство, чтобы его было здесь больше видно. Это с создания пула, на котором мы будем рисовать. Берём пул вот слева на кнопочку, переносим его. Пул создан. Пул назовём. Обязательно нужно пул называть. Это обычно всегда процесс согласования кадрового приказа. Можно указывать, в какой системе это делается, если вы не планируете, допустим, какими-то дорожками или ролями выять этот пул. Так, стартовый триггер у нас уже есть. Обязательно стоит его подписать. Допустим, у нас есть потребность в приказе. То есть ни в коем случае не стоит оставлять неподписанные стартовые триггеры, потому что непонятно, с чего у вас всё началось, что было входом, что пришло на вход. Это классика, допустим, тоже вот если брать нотацию IDF0, всегда что-то есть на вход. А создаём следующий процесс. Как создать следующий шаг? Это вот буквально нужно вот здесь вот не нужно брать и переносить вот этот шаг квадратик. Просто выделяем вот здесь. Нажимаем добавить задачу. Вот тут вот прямо шаг. Оп. И у нас добавился шаг. Процесс или задача. Создать процесс. Создать приказ. Создать приказ. У нас создаёт приказ кадровый работник. Я не буду использовать дорожки. Как создавать дорожки сразу? А давайте покажу. Если вы хотите пимент через дорожки создавать, в правом верхнем углу выделили пул. Можете здесь добавить добавить дорожку снизу. И у вас появится дорожка. Можете здесь каждую дорожку подписать, например, кадровый работник. А это будет у вас, допустим, 1Суб, к примеру. То есть это не обязательно человек и так далее, там руководитель 1сдо. можно, соответственно, на каждой, а-а, дорожке у вас будет, а, выполняться именно ей управлять этими задачами именно вот этот участник, который указан в этой дорожке. Всё, в принципе, просто. Ну, я пойду по простому пути. Я не буду использовать дорожки. Я пойду по рекомендациям Дениса Котова. Стараться не использовать дорожки, если их можно не использовать. Конечно, да, бывает требования от бизнеса обязательно за участников отражать в дорожках и там не отвертишься. А как мне обозначить всё? Ну, мне нужно всё равно обозначить, кто конкретно выполняет эту задачу. Её я могу обозначить следующим образом. Вот здесь нажима справа у меня есть а панель свойств. И здесь у меня есть так называемая viброль. Могу создать новую роль. Назову её кадровый работник. Это у нас человек. Выберу цвет. Пусть будет зелёненький, позитивный. Он у нас создаёт приказ. Приказ он создаёт не просто так, а в системе 1Суб. Нам, как архитекторам, как разработчикам, важно всегда понимать, аналитикам, в какой системе конкретно что делается. Переношу систему, называю 1С её зуб. Data storage. Вот он, если что. Или его называют хранилище данных, если перевести с английского. Направляем стрелочку. Видите, пунктирная, то есть не оббязательно. Это значит у нас, э, не обязательность, не основной поток. Здесь мы создали данные в зупе. Следующее, мы создаём документ, создать документ приказ, который у нас будет создаваться автоматически в 1С документооборот. То есть мы создали приказ в зупе. Далее у нас автоматически этот документ должен создаться в документообороте. А, да, мы можем написать, на самом деле, аа, выделить прошаг, создать на основании приказа документ в до, то есть подменю создать на основании, отправить приказ в ДО. Ну, я так заведомо специально не буду делать, потому что я считаю, что в рамках одного создать приказа все эти подряд функции кадровый работник как раз и выполнен. Это считается правильным с точки зрения БПМНА не повторять ряд операций, потому что приказ он создаёт, что-то там заполняет, какие-то кнопки внутри него нажимает, в том числе записать, в том числе и отправить приказ в ДО. Он нажимает. По итогу у нас дальше происходит процесс автоматически. Это создание документа-приказ в документообороте. Пишем создать документ приказ. Не пишу в документообороте, я его укажу. Вот здесь мы с вами используем третий уровень процессный. И здесь я подпишу, что это у нас 1С документооборот. Ну, соответственно, можно указывать, как у вас в компании называется данный документ. Обязательно я здесь укажу тип вот на карандашик нажимаю, что это автоматическая задача. То есть всё, что нужно, работник сделал, заполнил, нажал, и автоматически у нас происходит бесшовный обмен. И в документообороте у нас появляется волшебным образом приказ. Так, а можно здесь дополнительно выделить роль. Так, также выделяем создать роль, например, там процессы там рек. То есть у нас это там по рекзаданию. Ну ладно, давайте не будем выделять. То есть можно выделить какую-то систему, что как будто у нас фоновые задания, какие-то фоновые задания у нас производят обмен. Можем, можем, можем это выделить, можем не выделять. На самом деле мы обозначили вот этим ярлычком, что это у нас автоматический процесс. Так, следующий у нас процесс, который стоит выделить - это, то есть мы сейчас находимся в 1С документооборот. Нам надо выделить процесс, запустить процесс подписания. Процесс подписания. Запуск процесса подписания у нас будет идти автоматически. тоже я здесь ставлю. Так как я уже поставил, что у нас приказ создался в документообороте, то у меня, значит, и процесс будет подписания запускаться в документообороте. Можно, опять же, тоже роль фоновое задание выставить. Так, есть вопросы, я вижу. Давайте быстренько, чтобы их не накопилось и они не ушли далеко от темы. Потребность повышения эффективного штатного расписания. Нормально ли, что поток управления, а не информационный поток, переходит с дорожки на дорожку? С дорожки на дорогу. Да, конечно, Василий. Да. Когда если у нас внутри дорожки, это разные участики, между ними мы можем, а, показывать потоки. Это вся суть BPмена. Мы можем использовать эти дорожки, можем их не использовать. Тогда обозначаем либо цветом, либо вот, если нам редактор позволяет, выделяем в виде ролей. Андрей, а где потом хранить эти схемы? А хранить мы можем с вами схему сохранить. Дальше мы можем с вами, то есть она будет внутри системы сохранена. Это раз. В дальнейшем мы можем к ней обратиться. А, то есть она у нас тут у нас будет в списке. А, да. И мы можем эту схему экспортировать. Справа кнопочка экспорт. И мы можем экспортировать в классический формат BPM IO. А выбрать BPMN, чтобы, допустим, её загрузить. Мы её можем загрузить, допустим, в BPMAN IO редакторе, можем в шторм BPмен загрузить, можем в этот же редактор чуть позже загрузить, если мы хотим, ну, мало ли, вдруг тут не доверяем вот это место хранения. И правильно, лучше сохранять. И, соответственно, ещё можем выгрузить в форматах, которые доступны будут пользователю. удобный для вставки документа СВГ формат векторный и PNG формат в виде картинки. Вот, то есть BPM классический и два формата для отображения. Так, а как сделать доступными для пользователей? Как сделать доступны для пользователя? Ну, тут, Андрей, эти пользователи должны быть зарегистрированы, и вам надо перенести его в команду, то есть добавить команду. вот отдельно команду, но создавать команды пока я вам тут нужны допва, то есть если будет такая потребность, я могу сам эти команды создавать, пока эта функциональность влоб закрыта. Так, поэтому передать пользователям лучше через вот СВГ, PNG, либо BPM сохранить и потом можете импортировать. А, Андрей спрашивает: "А справочник ролей? в этой системе есть или он создаётся ситуативно. Справочник ролей отдельно создаётся для каждой диаграммы. Общего справочника ролей пока нет и не планируется. То есть в рамках каждого бизнес-процесса вы создаёте свой пополняете этот справочник и используете эти роли. Так, актор спрашивает: "А как отредактировать роль?" Отредактировать роль в правом нижнем углу закладочка роли. Здесь вы вот можете их отредактировать, сменить, например, свет, фоновые задания, поставить цвет розовый. Будет вот розовый цвет или переименовать. Так, Евгений спрашивает: "А как вообще понять, что за нотация используется на диаграмме? Где-то написано или это понятно по элементам, которые используются?" Повторно задаю вопрос выше. Извините, Евгений, да, может не увидел, да, вопрос. Ну, в данном случае это редактор специализированный под BPM. Соответственно, вот здесь вот слева все возможные элементы, которые есть только у BPНА. Что-то левое вы сюда привнести не можете. Вам сам редактор это не даёт. То есть это редактор для нотации BPM. Возьм зайдёте в BPM. Iio, там будет то же самое. То есть строго ограниченный вот этот набор инструментов, а, который я вам рассказал. обозначают строго саму нотацию VPM. Так, а если да, Евгений, непонятно ответ, пожалуйста, да, перефразируйте, дополню, как могу ещё. Андрей, и наполнение роли должностями и физлицаями. Есть пока только вот название роли у нас есть и тип роли, и цвет. Вот если возьмёте шторм BPM, даже в платной версии у них строго такой же функционал, да. Вот. А так идём дальше. А-а, по процессу запускается у нас процесс подписания фоновый, и дальше у нас идёт подписание документа руководителем, то есть руководителю приходит на подпись. Создаём следующую задачу, называем её подписать документ. То есть руководитель должен подписать документ. Не нужно делать три или четыре ээ задачи. Например, ошибка будет, если вы сделаете задачу открыть документ. А открыть документ, прочитать документ, подписать документ, ещё что-нибудь. Всё это делается в один поток одним и тем же руководителем. Коллеги, одну секундочку, сейчас свет включу. Поэтому мы с вами делаем строго одну задачу, где у нас взаимодействие делает с подписанием документа руководитель. То есть не делаем 10 подряд задач. Бывает, я такое вижу. Например, это руководитель. Руководитель человек. Давайте ему так есть. Аа он у нас обрабатывает, в общем, вот эту задачу и её итог - это подписание. Дальше он у нас может подписать, а может, предположим, отказать в подписании. Давайте отработаем эту ситуацию. Ставлю я разделительный шлюз. И в разделительном шлюзе у нас пойдёт два направления. Первое направление: нет. А, то есть сначала мы подпишем обязательно шлюз. Приказ подписан, а процесс у нас подписания приказа. Приказ подписан. И если нет, то у нас будет завершить процесс отказом. Завершение показом отказом у нас будет автоматически делаться. Ставим задача тип сервисная. и поставим роль фонновые задания. А давайте другую ситуацию. Если у нас приказ аа подписан успешно, подмечаем, что да, плюс ещё есть такая штука, как а поток по умолчанию. А рекомендуется её тоже ставить, но не обязательно, если вы подписали, что да, идёт, то поток по умолчанию не обязательно ставить. Но м в данной системе, как в шторм БПМЕ, так и вот в BPM есть возможность валидации этой схемы. То есть мы в конце, когда завершим эту схему, мы её провалидируем. И может, по-моему, у меня сейчас включена ошибка, что если не указано в разделении, а основной поток управления, он об
этом даст замечание. Оно не критично, но тем не менее будет замечание. То есть так называемый Happy Pass путь у нас должен видеть виден быть. Это вот какая вот маленькая вот здесь вот чёрточка обозначает основной поток. Вот. Но опять же, не обязательно, когда мы их подписали, эти потоки. А важны такие вещи обычно, когда вы автоматизируете, например, этот модель рисуете для BPMS системы. Там, конечно, тоже в обязаловке. Ну и лучше сразу привыкать, сразу делать по уму. Пишем завершить процесс подписания. То есть у нас здесь срабатывает тоже автоматика. А обращаю внимание, всё это происходит у нас в 1С документообороте. Вот тут мы его, коллеги, обозначили, когда у нас состоялся обмен, а, по бесшовной интеграции. Про бесшовную интеграцию, на самом деле, мы можем, а, написать отдельно, если нам требуется уточнение. Мы можем, допустим, сделать вот такую вот аннотацию. Бесшовная интеграция. Бесшовная использовалась бесшовная интеграция. То есть, если нам требуется какое-то пояснение к какому-то процессу или ещё чему-то, шлюзу, можем добавлять аннотации. Это нормально, это хорошо. Не стоит эти аннотации вписывать внутрь процессов.
Так, завершить процесс и давайте с нет разберёмся. Так, это ж дисклик. Я сохраню на всякий случай, чтобы у нас ничего не пропало. Создаём следующую задачу - это отменить приказ. отменить приказ. И отмену приказа у нас делает делает как раз а задача выполняется пользователем. Тип её делает кадровый работник. Дальше после отмены приказа у нас происходит отказ в подписании, то есть завершение процесса после отмены приказа отказ в подписании. То есть процесс на этом этапе мы завершаем. Соответственно, по позитивному пути, если мы идём, у нас здесь завершить оформление. И мы тоже ставим кадрового работника. Задача выполняемая пользователя и роль ставим кадровый работник. И обратите внимание, вот эти штуки у нас, э, кадровый работник должен выполнять в зупе, потому что кадровый работник работает внутри зуба, не внутри 1С документооборота. Мы должны зуб здесь опять показать. Я могу скопировать текущий зуб. Вот здесь его поставить. Можно, конечно, отсюда стрелочки протянуть, но это не очень будет красиво. И отсюда протяну, что у нас идёт обращение к зуб от отмены приказа и от сюда завершить оформление. То есть он у То есть у нас здесь опять же тоже произошла бесшовная интеграция. Можно здесь же это тоже пометить, например, в аннотации, что обратный обмен произошёл с помощью бесшовной интеграции в рамках нашего процесса. А, и показываем зуб. Соответственно, в зупе у нас отразились нужная информация. Так, и завершить оформление. Мы также здесь завершаем процесс. Давайте я его подпишу. Приказ подписан. Сохраняем. Так.
Андрей спрашивает: "А в какой момент в зуб передалось?" По сути, у нас задачи в зуб не передаются. Это бесшовная интеграция. То есть в зуб обмена не было. Здесь сам кадровый работник, он получает уведомление через механизмы бесшовной интеграции. В этом, в процессном уровне мы не показываем. Если нам требуется детализировать вот именно как у нас поэтапно идёт работа аа механизма бесшовной интеграции уже без кадрового работника, здесь нам может подойти хорошо как раз sequence диаграмма. То есть на sequence диаграмме мы можем показать, что в какой момент там отражается. Я на самом деле именно SIPNIS, а бывало рисовал. Если мне не нужно было кадрового работника в целом отразить, но здесь нам есть потребность отразить и с учётом участника. И, как вы видите, довольно-таки понятно всё получается, мы всё понимаем. То есть м так используется используется бесшовная интеграция. Вот, в принципе, всё понятно. Это называется процессный уровень. Так.
Так, коллеги, если есть по процессу вопросы, пожалуйста, задавайте. Если нет, не забываем, да, можно сохранить, можно экспортировать, например, в BPM аа формат PNG. Если я открою, у меня картиночка откроется вот в таком вот виде у меня картиночка полностью красивая открылась. Её можно вставлять в ваши документы, в том числе и можно пронумеровать. Допустим, нумеровать можно всё, можно нумеровать только задачи. Нумерация полезна, когда мы оформляем это для документов, тех же частных технических заданий или иных документов, где ещё требуется словами это дописать. А дополнительно здесь есть механизмы подготовки документации через искусственный интеллект, но это уже как дополнение, если вам это необходимо. Вот. А в любом случае вы должны сами этот процесс уметь понимать, уметь рисовать. Если через искусственный интеллект, скорее он вам, да, может что-то нарисовать, но итоговые детали, регулировку всё равно делать вам. Пока искусственный интеллект не может грамотно и качественно BPMN аа реализовать, хотя я веду над этим работу. А так, Андрей спрашивает: "А документы, электронную карточку можно запустить между задачами?" А документ или карточку? Здесь я вас, Андрей, не понял. Уточните, пожалуйста, вопрос. Что за документ или карточку? Если касаемо схемы, да, схема сугубо такая демонстрационная. В рамках процесса вы можете что угодно здесь добавлять, дополнять.
Так, коллеги, да, давайте подведём с вами итоги. Аа, коллеги, важно использовать специализированные инструменты моделирования. Так, Актус Бас спрашивает: "А расскажите про развёрнутый процесс?" А, пожалуйста, да, уточните, что значит развёрнутый процесс, что именно рассказать, про какой момент там иконка. Так, давайте посмотрим, что там за иконка. Так, так, так, так, так. Где именно? Скажите, пожалуйста, иконка провёрну развёрнутый процесс слева. А вы имеете в виду вот вот вот это свёрнутый процесс? Развёрнутый. Вот это это виды шагов. Шаги, соответственно, бывают у нас в виде подпроцессов. Подпроцессы характеризуются так называемыми либо свёрнутыми процессами. То есть, если я нажму свёрнутый процесс, у меня появится вот здесь плюсик. Значит, а это будет обозначать, что внутри него я могу его детализировать. Нажимаю вот на эту кнопочку Open, и у меня открывается процесс внутри подписания документа. И здесь я уже могу дополнительно что-то отразить, какой-то свой микропроцесс. Например, вот как раз технический уровень, про который я вам рассказывал. Вы можете здесь отразить, выделить, допустим, какие-то обработчики событий. Вот. Можно выбрать другой тип процессо. Называется он развёрнутый под процесс. Ну, развёрнутый, давайте сейчас я выберу. Он нам единственное сейчас некрасиво будет. Он сейчас нам его собьёт наш. Давайте я верну. Ай, здесь я здесь всё уберу. Уберу обратно верну и рядом лучше другой. Так, задача у нас кто там кад этот руководитель. Кстати, давайте проверим валидацию. Vibeчек. А требуется название элемента. Так, а, ну, название, да, потому что мы что-то вводили, он, видимо, пустое запомнил. Так, а в целом, да, в остальном у нас ошибок здесь нету. Так, то есть, если бы я здесь дорожку не называл, он бы ошибок не выдал. Он запомнил, что она здесь пустая строка. и показывать. Так, как выглядит развёрнутый процесс? Ниже перенесу плюсик, разверну развёрнутый процесс. И он выглядит вот таким вот образом. Это то же самое, что свёрнутый, только мы в рамках одного окна вот это всё показываем. То есть внутри у нас заходит поток, внутри заходит поток, и мы в рамках него моделируем. Как-то так. Это выглядит так свёрнуто. Тоже используют, но не так часто. Всё-таки свёрнуты удобные в отображении. Но если вам надо на одной диаграмме всё показать, то и развёрнуто тоже можно. Подробнее, что какой значит, если вы зайдёте через Vib, можно вот здесь нажать справочку. Я попытался максимально её собрать. Всё самое нужное. Здесь всё максимально расписано. Например, про подпроцессы какие бывают, а расписано, то есть сами типы задач, какая для чего используется, тоже расписано. Здесь, ну, такая маленькая справочка, но, как мне кажется, полезна ссылками на материалы источников собрано. Так вот, ну, не забывайте в конце vibeчек проверять, что у вас точно ошибок нет или их минимум. Так, давайте здесь заполню чем-то. Вот всё. Вот у вас должно ошибок не обнаружено. Это важно, потому что, допустим, какие ошибки частые процессы ни что на что делать не отвечают или, допустим, схема идёт не слева направо, а, допустим, сбивчивая. Вот такая вот. Вот это тоже будет некорректная схема. Система сразу об этом скажет, что поток задач у вас движется, должен двигаться справа налево, а у вас он не некорректно. То есть нужно поправить. Соответственно, исправляем, нажимаем, ошибок нет. Удобно.
Кратко по итогам, коллеги. Рекомендую использовать специализированные инструменты моделирования. Вы видите, вот мы сейчас использовали инструмент, а есть аналоги, само собой. А он прекрасно подходит для того, чтобы моделировать диаграмму в BPмене. Да, он не сможет нарисовать EPS sequence диаграммы, но на то и заточен данный инструмент, только на BPмен. Именно такие инструменты дают максимальный профит, максимальную скорость для того, чтобы их, э, получить нужную диаграмму. Для простых интеграций, коллеги, без условий старайтесь использовать UML sequence диаграммы. Всё-таки это наиболее удачно. Если у вас что-то маленькое, особых максимум одно витвление альтернативное действие есть, то, конечно же, используйте SEQнс диаграмму. Не надо ничего выдумывать ни BPмена, ни APC, а именно SEQ. Это важно для сложных интеграций, где требуется отразить сложные какие-то условия, ветвления, возможно, циклы. Ну, у нас, коллеги, с вами не такая сложная была диаграмма, но тем не менее, если бы возникли ещё большие ветвления, циклы, здесь уже довольно неплохо показывает себя BPM. Опять же, тоже нужно его правильно использовать с точки зрения уровней. Я сегодня рассказал вам про четыре уровня. И уровни можно комбинировать, но комбинировать стоит там максимум два уровня. Не стоит сразу там три-четыре в одну кучу собирать. Если вам есть такая потребность, нарисуйте отдельные диаграммы. Вам никто не запрещает. Сначала концептуальную, может быть, а дальше межпроцессну межпроцессную с процессными, ну либо отдельно там межпроцессную тоже выделите, разделите их. То есть не нужно всё в одно смешивать. В BPM при построении схем важно соблюдать всегда стараться единый уровень детализации, соответственно, в том числе и с учётом уровней, про которые я вам рассказал, но можно их комбинировать. В BPM при необходимости шаге процесса можно укрупнять и объединять в группы, то есть выделяете в подпроцессы, сворачиваемые, разворачиваемые и так далее. Это окей. А Василий пишет: "Не тупит как шторм". Кстати, шустро всё. Да, Василий, моя цель, когда я создавал этот инструмент, была номер один. Это чтобы это работало быстро. Я преклоняюсь перед Денисом Котовым. Честно, будет смотреть, если то ему как бы респект. Но его БП этот шторм, ну, так тормозит столько рекламы, честно. М, да, тяжело, тяжело работать. Да, даже с подпиской. У меня была подписка корпоративная, даже с подпиской тоже был тяжеловат, поэтому мне потребность была вот в маленьком, быстром редакторе, ну, и с поддержкой ролей и ничего лишнего, чтобы не было. Вот я такой создал и сейчас использую активно. в том числе на курсе архитектор 1С, коллеги, на на курсе архитектор 1С мы всё это более глубже смотрим, как использование BPMN, использование Sequence диаграмм, использование C4. Там, конечно, всё это мы погружаемся детально. А так, да, ссылочку на курс, да, если про курс, то сейчас, коллеги, ещё немножечко я расскажу про курс, в рамках которого у нас происходит с вами вебинар. Курс называется Архитектор 1С. В рамках курса мы проходим на нём а всё, что связано с архитектурой 1С. Здесь имеется в виду архитектор не функциональный, а именно технический архитектор. Мы проходим основные настройки окружения ДНС, как грамотно, а, настраивать СУBD, такие как MSSQL и постгри. А-а, проходим организацию скрамкоманды на проектах 1С, как их грамотно команды по чек-листам запускать, обучать и всё прочее. Дальше у нас большой блок - это моделирование писания бизнес-процессов. Здесь как раз мы глубоко проходим различные нотации, как раз вот C4, BPMN и другие м необходимые артефакты, которые должен уметь делать технический архитектор. Дальше мы глубоко погружаемся в автоматизацию работы разработчиков и контроль качества хода. Здесь мы изучаем, соответственно, использование таких вещей, как OnePT, sonar cou и многое другое. Принципы кодарев, разработка по Gitflow, как с использованием хранилища, так и с использованием ЕДТ. Дальше блок тестирования в 1С и использование седя и CD на проектах. Здесь мы погружаемся в тестирование, рассматриваем сценарное тестирование на Vaness Automation и на Якт модульное тестирование. И всё это дело показываем, рассказываем, как запускается в рамках Дженкинса. Да, мы GitLab C не рассматриваем, но в рамках курса смотрим только Дженс. Но зато в рамках Дженкинса мы ещё отдельно смотрим библиотеку Jenkin Sleep, как правильно с нею интегрироваться, всё настраивать. и запускаться. К сожалению, не все это умеют. Библиотека классная. Jнkinsleep. Следующий пункт - это мониторинг и контроль производительности. Здесь по классике основные моменты по мониторингу производительности. Здесь мы показываем, как можно эффективно настроить, например, а Прометеус с графаной связку. Ну, и как вообще производить, мониторить производительность, какие-то аспекты эксперта по тех вопросам мы здесь охватываем. Не так глубоко, конечно, как на курсах связаны с экспертом по техпросам, но тем не менее. А дальше блок построения интеграции в системах 1С. Здесь у нас рассматриваются такие событийные интеграции, как Rabit MQ, Кавка. Плюс мы рассматриваем бесшовную интеграцию с документооборотом. А как-то так. Всё это дело у нас завершается проектной работой, где мы суммируем наши знания, и вы реализуете уже проектную работу с вашим проектом, который вам интересен, ну либо который вам понравился из предложенных тем OTUS. Дальше вы эту проектную работу защищаете успешно. Ну, этим самым программа курса для вас будет завершена. Преподаватели. Преподаватели несколько человек, не четыре. Здесь четыре отображено. Аа Олег Коратаев, я Никита Иванченко, известный open source, автор различных библиотек ванскрипта, выступающий, действующий докладчик, спикер инфостарта и других конференций. Лада Берестовская, опытный руководитель проектов. Сергей Каменский тоже очень опытный, э, бывалый рукодитель отделов различных, рукотель проектов. Эти коллеги тоже много что рассказывают в рамках курсов. То есть у нас не один конкретно закреплённый преподаватель, а именно несколько практиков. То есть вот эти четыре основные, но есть ещё и дополнительные ребята, которые много чего интересного рассказывают. Все, ну, как бы являются практиками. Здесь нет ни одного у нас теоретика. Обучение на курсе проходит у нас в живом формате. Постоянный нетворкинг, как вот сейчас я с вами проводил. Идёт общение, соответственно, на курсе там и голосом общаемся, разбираем вопросы. Плюс есть и дополнительный чат, в рамках которого у нас дополнительно идут разбор всяких вопросов. Плюс домашние задания сдаются на платформе OTUS. Довольно удобно. Там вы задаёте задание, получаете развёрнутый фидбэк. А программа обучения на курсах у нас постоянно обновляется. Каждый запуск он, можно сказать, как новый. То есть, ну, много что меняется, изменяется, потому что вы сами видите, как у нас всё здесь вовсю растёт уже. Вовсю искусственный интеллект внедряется. где-то мы его стараемся аккуратно добавлять, но пока не сильно, потому что всё-таки по искусственному интеллекту чётких методик ещё нет. Вот. А мы всё-таки акцентируем наш курс на какие-то методологические моменты, важные, которые с которыми вы изучите и уйдёте и будете их использовать не один месяц, а год и более, может быть, 5, может быть 10 лет. То есть мы на вот такие моменты акцентируем именно фундаментальные. А курс у нас стартует ближайшие 29 апреля. Длительность обучения 4 месяца с лишним. В хорошем в таком формате проходит два раза в неделю. М воне рабочее время полтора часа вебинар. Очень удобно. Кому интересно, коллеги, QR-код сканируем и регистрируемся. Проходим вступительное тестирование. Так, Василий пишет: "Если опыт разработки именно в 1С немного совсем, но большой опыт разработки в другом стеке, а в 1С только опыт аналитики, будет сложно въехать". Василий, попробуйте пройти вступительное тестирование вот по QR-коду. Если у вас там будет ок, то, соответственно, вы, да, подходите, потому что, конечно, да, здесь требуются знания разработчика 1С прежде всего, то есть надо уметь разрабатывать, нужно понимать, как как разработка делается на 1СЕ. Вот если, ну, как бы в этом деле плаваем, то лучше сначала рассмотреть курсы разработчика 1С. А если вы уже уверенный разработчик 1С и хотите себя развивать дальше до уровня архитектора, то, конечно, заходите, вам понравится. Да, если есть вопросы, коллеги ещё, пожалуйста, задавайте. А я подведу итоги. Мы с вами сегодня познакомились с типами с типами нотациями для отображения интеграции возможными. Плюс большое спасибо коллегам, что тоже меня дополнили дополнительными. Ещё вот коллега Андрей меня дополнил SДК. Тоже диаграмма SDL. SDL. Вот SDL, что тоже используется, я её не знаю. Ну, здорово. Тоже буду знать себе записал. А дальше мы разобрались с уровнями отображения интеграции именно BPM. какие уровни бывают и как их можно компоновать, использовать. Далее на практике я вам промоделировал BPMN, показал, как можно отобразить на процессном уровне аэ end to end процесс начала до конца с видимым результатом. Что это нам в итоге даёт? Даёт понимание и контроль взаимодействия систем в процессе. То есть, ну, мне кажется, крайне эффективная штука. Предлагаю вам использовать это на практике. Используйте, и у вас всё получится. Коллеги, пожалуйста, заполните опросы мероприятия. Я сейчас вам ссылочку скину. У вас это займёт буквально секунд 10, а для меня, для команды US это очень важно, потому что, ну, если да, опросов, если никто не заполняет, соответственно, открытые уроки, значит, могут сделать выводы, что никому интере не интересно, значит, и проводиться они не будут. Поэтому, коллеги, если хотите, да, чтобы всё окло, пожалуйста, заполните. Секунд 20 у вас займёт. И коллеги, да, всем спасибо за внимание. Приходите учиться US и приходите обязательно на открытые уроки. Так, пишут, доступ запрещён. Сейчас я сам попробую зайти там. Там да. Так, коллеги, да. Угу. Сейчас, секундочку. Угу. У меня тоже. Да. Одну секундочку. Так, коллеги, да, я думаю, сейчас поправят. Странно, да? Почему вдруг он там у них запрещён? Коллеги, в любом случае, да, опросник вам придёт ещё на почту, пожалуйста, да, его не игнорируйте. То есть там три-четыре пункта заполните. А, надеюсь, вам было полезно. Да. Алина пишет: "Чтобы пройти опрос, нужно быть зарегистрированным на платформе OTUS US". Алина, я зарегистрирован на платформе Otus. А у меня тоже, у меня тоже 403. Так что, Алина, у меня также. Да. Так. А это Алина. Это с нашей поддержки. А, да, да. А, Алина уточнила, преподаватель не может, да, коллеги, да, пожалуйста, зарегистрируйтесь на платформе OTUS, там введите, пожалуйста, логин, пароль. Думаю, там тоже пять пять 10 секунд у вас займёт. Всё, коллеги, всем спасибо. Да, и жду вас на следующих открытых уроках. Алин, пожалуйста, помоги коллегам. Да, всё, спасибо, коллеги. Всем до скорых встреч.