Начните писать здесь...
Расшифровка видео:
Сейчас приглашаю Владимира Владимировича Репина и попрошу его сделать доклад, может быть, 15-20 минут, чтобы осталось время на вопросы, потому что вопросы – самая важная часть нашей конференции, именно для чего я прошу в реал тайме, все остальное можно сделать в записи. Человек этот в представлении особо не нуждается, он завоевался. Стоя место – это один из лучших процессников, в том числе умеет в модели. И почему я его пригласил?
00:30
потому что один из самых печальных для меня трендов, хотя я сам разработчик, что люди упираются в инструментальные возможности, пытаются изобрести какую-то IT-систему, которая вместо нас будет работать, пытаются, не наводя порядок, затолкать все это, как в шкаф или в чемодан на курорт, затолкать все это, не разбирая, привести в порядок. Именно вопрос о том, что если бы...
00:57
У меня была возможность, я бы делал технические задания сначала нефункциональные требования, потом бизнес-требования, а потом только функциональные возможности. Потому что большинство заказчиков начинают рассказывать, ну, учить программиста программировать. У нас в это очень много вложил сил Турусов, он эту модель продвигал, что сначала давайте наведем порядок в процессах, а потом будем все это автоматизировать.
01:25
иначе мы получим афонетизированный хаос. И поэтому я пригласил человека, которого лучше послушаю, про себя и так все знаю. Владимир Владимирович, пожалуйста. Да, спасибо большое. Я хотел спросить, сейчас меня слышно? Вас слышно, хорошо, продолжайте. Я, честно говоря, что-то думал, что у меня 15 минут будет, почему-то отложилось. На самом деле, то, что у меня чуть больше, это хорошо. Я тогда, наверное, спокойно изложу тему и, соответственно, отвечу на вопросы, если они возникнут. Да.
01:54
Назвал я тему автоматизация бизнес-процессов и роль модели в нотации BPMN Такая на мой взгляд немножко провокационная тема, казалось бы, как по-другому. Но вот оказывается можно Кратенько буквально уважаемые коллеги я себе скажу. Я заканчивал в фистех, потом так получилось, что попал в консалтинг. Сейчас работаю в области процессов уже много лет веду проекты как процессный архитектор, как методолог, где-то как аналитик
02:23
свободное время, когда бывает, издаю книжки, которые выходят вот слева здесь, там есть, вот последняя была понотация BPman, сейчас тоже новые книжки делаю. И собственно как консультант, к качеству платформы внедрения, вот процессного управления, мы уже много лет используем Business Studio, сейчас мы используем шестую версию системы, в которой два редактора, это редактор Vizio и встроен уже летом, ну к мае будет уже
02:52
на этой системе и, собственно, дальнейшее изложение будет идти с точки зрения как раз консультанта, который в компании внедряет процессное управление, используя как платформу систему Business Studio в качестве инструмента для проектирования анализа процессов. Дальше я пойду помедленнее. Смотрите, вот понятно, что любая информация, которая вот излагается, она излагается с определенной
03:21
точки зрения, с определенной культурой, с определенной опытом. В данном случае мы рассматриваем нотацию BPMN как некий международный стандарт, созданный в свое время для унификации работы по проектированию исполняемых процессов в low-code системах. Мы рассматриваем этот стандарт и мы рассматриваем конкретные проекты, которые могут быть реализованы с использованием BPMN. И вот здесь первое, что хочу сказать, что эти проекты
03:51
Одно дело, когда вы используете BPMN в изначальном варианте какой-нибудь low-code-системе, например, как здесь показано, вы заходите в безаджи, например, и соответственно в безаджи проектироваете исполняемый процесс и потом соответственно запускаете исполнение. У меня, кстати, там есть такая оранжеваненькая книжка, вот она здесь, это практикум на безаджи, она была написана в свое время.
04:17
Там понятно как бы BPMN в своем изначальном варианте работает. И, собственно, основная задача там это отрисовать алгоритм процесса, а все остальное, то есть это уже сбор данных, там, да, экранные формы, создание структуры данных, создание вот этих вот правил переходов, выражений и так далее, и так далее. Это уже все вне системы, ну, практически собираются и делается. То есть разработчик, который информацию увидит...
04:44
но на модели BPMN это информация о данных, о структуре данных, о документах, которые движутся Она там просто физически не нужна при настройке Другая задача, когда, например, мы еще не выбрали конкретную low-code-систему но мы, допустим, хотим глубоко понять процессы и, по сути, сделать некое техническое задание на его автоматизации Вот то, что показано чуть выше
05:08
Здесь эта модель нарисована тоже в нотации BPMN, но с некоторыми доработками это мы делали в бизнес-студии. Здесь мы на этой модели дополнительно указывали конкретные вот комментарии, что мы хотим при выполнении каждой задачи, какие нюансы. К ней прикладывали форму протокола разногласий и соответственно форму договоров. То есть это по сути модель согласования договора с клиентом. И вот на базе этой модели нам коллеги в свое время из ELMA
05:37
на Yelm 365 они нам за неделю фактически сделали прототип, работающий этого процесса с экранными формами, кнопочками, со всеми вещами. И потом сидела рабочая группа UrisConsult, договорники сидели, аналитики, они это работали, дополняли в режиме Agile. Я хочу сказать, что вот такого рода процессы, этот процесс, можно сказать, что он простейший, по сути своей. Тут немного задач.
06:05
достаточно стандартная логика параллельного согласования с возможностью возврата на конкретного согласования Процесс простой. И вот для таких процессов как раз вот моделирование в BP-MAN прекрасный инструмент для создания именно TZ, такого не длинного, какого-то там большого гостовского TZ, именно TZ видеомодели с дополнительными комментариями для разработчиков. Поэтому вот это точка зрения. Консультант по управлению
06:35
Вот моя точка зрения сегодня, которая использует нотацию BPMN в конкретном программном продукте, который имеет свои функциональные возможности, особенности, расширяющие несколько нотаций с точки зрения выразительной способности. И моя цель такого рода проектов обычно следующая. Это полное описание процесса, полное аналитическое описание, с последующим пониманием, как он вообще выполняется, и последующая его оптимизация, улучшением трансформации.
07:05
Это моя точка зрения, моя задача. Метод как раз моделирования нотации BPMN с использованием дополнительных вещей я чуть позже о них скажу. Никаких секретов нет. У меня на сайте в конце есть контакты вся информация, примеры, какие так называемые статусы мы используем, как мы расширяем нотацию BPMN в Бизнес-студии. У меня это есть все. Это можно будет потом дополнительно посмотреть. Я просто сегодня хотел бы немножко вашего времени тоже сэкономить.
07:34
Вторая точка зрения, с чем приходится сталкиваться. Это, уважаемые коллеги, это топ-менеджер компании. Если у меня, как у консультанта, задача глубоко разобраться с процессом, понять его суть, понять его проблемы и ограничения, как его перестроить и сделать нормальное тз на автоматизацию, то топ-менеджер не хочет снисходить до этого момента, его важно, чтобы задача была решена каким-то средством.
08:03
При этом, допустим, попытка автоматизировать некоторые процессы кадровые в одной крупной очень организации, ну, очень около государственной, скажем так, привела к тому, что Токману сказал, нам это не надо, вот, на подпись меня несите на бумаге, я почитаю, да, вы что, представитель управления заставите заходить в систему, что ли, там какие-то кнопочки нажимать, зачем ему это нужно, ему и так все принесут. И на самом деле внедрение вот этой системы...
08:32
low-code система, хорошая, кстати, она упёрлась именно в нежелание руководства вообще как бы в ней что-то делать. Вот, а еще одна проблема, которую мы тоже наблюдаем, это нежелание руководителей погружаться в специфику метода инструмента. То есть, грубо говоря, там не царское дело изучать, вот, что здесь вообще нарисовали. Это что за кнопочки такие, квадратики там, зачем это вообще нужно, там, да. Вот, идите, сделайте мне как будет это работать. Но, к счастью, есть руководители, которые погружаются в это.
09:01
используют этот инструмент как рабочий, это тоже хорошо. Ну и подчас они как бы устраняются от того, чтобы принимать решения. И когда, допустим, процессный офис говорит одно, нам нужен такой процесс, IT говорит, что не, это сложно, дорого, там давайте не будем, давайте что-нибудь сделаем по-другому. Подряд человек говорит третье, что нужно вообще масштабное исследование, там нужно собрать функциональные требования и вообще там заплатите нам 35 миллионов, мы все сами сделаем.
09:31
Ну и как бы руководитель не всегда хочет влезать в эту всю специфику и соответственно глубоко понимать ситуацию и принимать решение, к сожалению. Ну как бы не царское дело. И это конечно вызывает оплённую проблему в работе консультанта или работе в процессной офисе. Коллеги иногда будут назад возвращаться. То есть на самом деле вот я сейчас как внешний консультант себя позиционирую.
09:59
но иногда я работаю как сотрудник внутри процессного офиса в разных случаях у меня какая-то вот проблема взаимодействия процессного офиса, который хочет процессы качественно отработать там и внедрить с руководителем, который не хочет снисходить и в этих процессах разбираться и менять что-то, его все устраивают и соответственно IT службы. Ну вот теперь по поводу IT службы.
10:29
Но потом понял, что это будет, наверное, некорректно, неправильно, потому что я не могу излагать точку зрения IT, я могу излагать свою точку зрения на точку зрения IT. Извините, вот такой коломбур получается. Вот точку зрения IT мы можем услышать и заслушать и так далее. Но как сторонний наблюдатель, что я вижу самом деле здесь? Я вижу условно, что можно назвать хороший IT, плохой IT.
10:55
Опять же слово хорошее, плохое это очень относительная категория, как и добро и зло. Хороший или плохой это субъективный взгляд на вещи, он с конкретной точки зрения. Вот допустим, опять же возвращаясь в мои точки зрения консультанта, который вот эти процессы для компании Мастерита проектирован. Хороший IT это IT такой, когда описание процессов нужно и очень помогает, особенно при наличии архитектуры.
11:21
И пример могу привести к компанию Fesco, которую мы когда-то в свое время делали проект по описанию процессов BP Man, это делали процессы работы CRM системы. И это директор по IT, он поставил эту задачу, и это нужно было, чтобы понять глубоко, какие вообще процессы в области работы с клиентом есть, что конкретно реализовано в CRM, чтобы потом можно было при необходимости перейти на другой CRM, понимая, что мы там конкретно внутри делаем, главное, как мы это делаем.
11:51
именно это была поставлена задача к директорам по it дальше разработка кастомизированных решений в рамках общей архитектуры с учетом it стратегии может быть сложная фраза но понятно что кастомизация такая глубокая она палка двух концах с одной стороны как бы мы создаем какое-то приложение удобное пользователю другой стороны мы отходим от каких-то типовых коробочных решений у нас могут возникать проблемы с обновлениями там ну и так далее и так
12:21
Ну и плюс мы должны, естественно, учитывать общую стратегию и как бы как у нас вообще архитектура выстраивается, чтобы не создавать каких-то монстров, которые потом невозможно будет санкциировать. Ну вот наблюдал в компаниях ситуация, когда допустим IT служба начинает мастерить какую-то внутреннюю программку для юристов или для безопасности или еще для кого-то, полгода ее мастерит, а потом выясняется, что то, что они там сделали, можно было на лоу коде сделать за две недели.
12:49
Это скорее к плохому IT. Дальше, что еще я катеризую как хороший IT? Это ориентация на эффективность снижения TCO, совокупность в томности владения, это высокая клиентоцентричность по отношению и к внутренним в первую очередь, и к внешним клиентам, и понимание необходимости цифровых решений для развития бизнес-моделей компании и повышения объемов продаж. Это хороший IT. Плохой IT.
13:17
плохой IT, описание процессов не нужно, это вредно, это только тормозит внедрение, нам это не надо разбираться еще в этих схемках ваших, вы нас фигней грузите. Я, коллеги, транслирую то, что фактически я слышу от некоторых IT-специалистов, которые даже смотреть близко не хотят. А зачем нам это надо? Давайте вообще не будем ничего кастомизировать.
13:46
Не трогаем штатный функционал. Я про 1s. Кабы чего не вышло, вдруг бы потом не пришлось тратить лишнее время на апгрейды какие-то там при накате новых версий или что-то еще. Минимизация усилий по разработке. А зачем я это буду делать, если мне за это не платят. Низкая клиентоцентричность. Лишь бы решение не упало и отвалите вы от меня. Значит цифровые решения, зачем они нам нужны.
14:14
Давайте просто сначала автоматизируем согласование договоров в 1С или вообще отправим служебку по маршруту в 1СДУ. Хотя сама по себе служебка, как сущность, она уже давно устарела и можно от нее отказываться. Было бы очень давно, но народ делает. А зачем нам это надо? Давайте рисуем решение морально устаревшие 20 лет назад на заре текстарта, как бы, вордфлова систем.
14:40
ну давайте это в СДО сейчас сделаем, толкнем там эту служебку и все тихо будут радоваться. То есть я считаю, что это плохой IT. Все же определяется ресурсом, наличием времени, денег, нанять хороших специалистов, взять IT-директора. У какой-то компании этого нет, IT-директора взять нельзя и все и приплыли. Соответственно, я хотел дальше вам два кейса рассказать на самом деле. Первый кейс.
15:07
Я не могу назвать подзапись название этой компании. Скажем так, это дочка крупной системы образующей системы образующего компании в нефтегазовой сфере. Это конкретный кейс, с которым мы столкнулись, мы для этого заказчика делали проект. Естественно, какие-то примеры схем VPMN или название заказчик я называть не могу. Значит, постановщик задачи генеральный директор. В условиях СВО.
15:35
сложилась ситуация, что нужно переходить западные ERP системы на 1s ERP. В порядке минимизация рисков. Значит, игроки на шахматной доске, генеральный директор, достаточно молодой такой, IT-директор мощный, вот мы со своей стороны. Дальше была такая задача, выбрали типовую группу процессов, выбрали процессы управления платежами.
16:04
там оказалось, что одним процессом не отделываешься, оказалось, что нужно описать группу связанных процессов, там формирование оснований для оплаты, разнесение вот этих, ну анализ на каждый день, состояние расчетов там с поставщиками, ну и там процесс дальше, собственно, формирование заявок на оплату, по сути, с их согласованием, передачей в некий корпоративный центр для согласований. Ну, в общем, вот так. Что в итоге получилось?
16:33
Еще раз хочу акцентировать ваше внимание на постановку задачи генеральным директором. Понять, что мы делаем ERP и перенести это в 1S ERP. Результат. Когда нарисовали процессия BP-MAN, причем не под автоматизацию, а именно под анализ. Что это такое, чуть позже скажу. Выявили огромный бумажный документооборот, при том, что это все делалось в ERP-системе.
17:01
выявили очень плохую интеграцию систем, то есть даром что это было в ERP, параллельно это шло в Excel, потом это распечатывалось, потом это шло в Outlook, потом где-то это голосом, потом это передавало спецсистему, потом банк-клиент и так далее. То есть нормальной интеграции с ERP не было и большое количество ручных таких вот переносов системы. И большое ножное хождение с этими бумажками
17:30
По сути, резюме это было в конце следующее, что уважаемые коллеги нельзя переносить процесс как есть без его радикального перепроектирования. То есть нет смысла его тащить в таком виде в 1S ERP. Зачем? То есть мы кривой процесс будем сейчас переносить в новую систему. Как вы думаете, какой был ответ генерального директора? Он посмотрел на все, как это делалось, а делалось следующим образом.
17:58
брали документы, читали, выяснялось, что в документах половины информации нет, проводили встречу, интервью с руководителями, специалистами, начальниками отделов, руководители говорили, что «ау, иё, иё, иё, мы вот это не помним, пойдем уточним», на неделю уходили уточнять, потом приходили, потом показания у них, как говорится, расходились, не бились между собой. В итоге оказалось, как вот мнение
18:28
у нас нет людей процессного офиса, нет денег на его создание и покупку системы. То есть вот на самом деле создание вот таких вот моделей, проработанных, продуманных, это естественно не бесплатно, это как бы требует серьезного времени, хорошей квалификации аналитиков, которые это делают, а ему нужно быстро перескочить. И тут слово берет директор по IT, говорит такую фразу, а я согласен, долго, дорого.
18:57
у нас специалистов по bpm нету и вообще зачем нам это нафиг надо сейчас мы справочники настроим перенесем данные настроим базовые функционалы пусть они работают то есть нам это как козе баян да то есть нам этот bpm у нас сейчас нету low-code системы мы в gp там это будем другим образом делать и вообще нам это ничего не надо вот такая позиция коллеги да это вот первый кейс когда допустим it
19:27
Директор со своей стороны говорит, что это не нужно, BPMN нам не нужен, это дорого-сложно, это наверное относится скорее вот сюда. И кстати, что я тоже сегодняшний утром, когда в зал ходил, по дороге тоже обдумывал доклад, и короче я пришел к выводу. Собственно, а почему вот, как говорится, петух в одно место клюнул и им нужно быстро перескочить за два месяца? Хороший руководитель, который смотрит...
19:56
театрически далеко идущим образом, он понимает, что ему определенный ресурс квалифицирован нужен. Если он понимает, что ему нужно своими процессами разобраться, то есть как бы это дело не одного дня, нужно создавать соответствующие подразделения, соответствующий ресурс, компетенции, этим заниматься постоянно. Потому что нужно наперед смотреть. А если этот человек пришел на год в компанию порулить, и потом он понимает, что сейчас он порулил, и у него в другую компанию его снимут.
20:25
и перейдут на другую должность. Понятно совершенно, что ему это вообще создавать ничего не нужно. Для него это просто лишний обузов. Это вопрос именно уже стратегии отношения долгосрочного такого. Второй кейс уважаемый коллегия, чтобы не злопотреблять вашим времени, это автоматизация в 1 СДО. Постановщик задачи генеральный. Задача автоматизирует согласование договоров
20:54
одобрение нового контрагента и так далее. Ну такой, знаете, рутинный, абсолютно стандартный джентльменский набор того, что нужно компании. Процессный офис выполнил описание процессов создания нового контрагента, проверки, т.е. голосования, договоров различного типа. Группа 1SERP настроила автоматизированный процессов ДО. Результат. Что видит процессный офис? Процессы ВДО упрощенная проекция реальных процессов компании.
21:24
здесь я уже говорил там на одном из своих вступлений что конечно до на мой взгляд это диалогически это что это процесс для документа то есть про документы это ключевое для него создаются процессы и по-жительному циклу документы да причем иногда упрощен а bpm и в low-code системах мы имеем документ или даже точнее данные для процесса то есть обратная идеология
21:53
И вот эта вот антологическая модель того же 1.S она как бы ну очень специфичная и если допустим антологию строим по другим более правильным принципам у нас как бы эффективнее это можно все автоматизировать. Ну вот ладно. Статусы в 1.S.DO отличаются от тех, которые запрашивал бизнес. Ну просто вот руководитель RP говорит, а не буду я сейчас никаких плодить новых сущностей, а к обычьему не вышло и не слетело при обновлении.
22:21
вот то что есть то и получите. И получилось что отображение реального процесса которое работает бизнес на 1s это упрощенный предельно кастрированный процесс который лишь бы что-то документы какие-то в системе появились. Плюс сама по себе автоматизация оказалась крайне неудобной очень много лишних контролов экрана экранных формах очень много нужно человеку пройти экранных форм.
22:47
Причем эти формы для людей, которые незнакомы, можно где-то нажать не то. Нужны сложные многостраничные инструкции пользователя, чтобы он не забыл, что нажимать. Ну, тут такая разработка. Опять же, я говорю, что это плохой IT. На мой взгляд. Может быть, я заблуждаюсь, но вы сегодня скажете. Опять же, процесс на Office рисую процессом BP Mania.
23:12
он был неким мостиком между бизнесом, то есть вот такие процессы он рисовал, он был мостиком между бизнесом и IT. То есть в этом проекте, слава богу, руко научились читать эти схемы, и они реальных использовали как некий инструмент для обсуждения того, как это должно работать. Вот поэтому взгляд группы автоматизации, ну там круто уложились сроки там, с минимальной доработкой штатного функционала. То есть со своей точки зрения у них все хорошо.
23:40
Процессный офис. Создали неудобный функционал на соплях и палках. У всех точки зрения на некую реальность они разные. Ну и немножко примера, как это визуально выглядит. Здесь маршрут подписания договора в 1С. Это согласование подписания договора. На подписание договора вообще три шага. А вот здесь слева и справа
24:07
но это я до конференции делал в прошлом году, рассказывал, повторение идет. Вот это процесс подписания договора. Почему его четыре разных варианта? Потому что мы можем подписать первыми на бумаге, первыми можем подписать контрагент, мы можем работать по скану сканов, мы можем подписать через диадок, или контрагент первый подпишет через диадок. У нас возникает разный сценарий. Самый сложный сценарий вот этот, когда контрагент подписывает скан скана,
24:37
и что-то там закупаем и так далее. То есть тут как бы идет сверх всяких версий документов, там прочее. Ну так вот, вот этот вот процесс, реально описанный в BPMN, показывающий все как это идет, его проекция на 1s вот всего три шага. Ну там, отправить на подписание, подписать, прикрепить оригинал. Все!
25:02
То есть программиста Aginess не интересует вообще, как это делается. То есть кто, кому, Юриев, скан, сверка, как сверяет, пофиг. Главное, сюда в Aginess затащите, поставить галочку, что оригинал получит. Понимаете вот идею, да? Вот возвращаясь к этому, почему я вот здесь написал? Высокая клиентацентричность, понимание необходимости цифровых решений. Он пишет, ребята, не дожируй, лишь бы что-нибудь сейчас быстро внедрить.
25:32
Я говорю, давайте здесь поставим, допустим, вот в этой части, чтобы скан, скан сверялся не юристом, он делал пополизную работу, да? А какой-то там, например, РПИ или робот и нейронка, там у Элмы есть решение, там она сверяла бы сканы с оригиналом, выдавала бы дельту, там, и если бы дельта отобнаружена, юрист бы подключался.
25:55
Зачем нам это делать? Вот вам прикрепите оригинал и тихо сидите радуйтесь. Вот это разница плохой и хорошей IT. Хороший IT смотрит на процесс в целом и хочет сделать его эффективным и цифровым. Плохой IT говорит, не ребят, мне это плевать. Вот документик движется, давайте его DNS посмотрим. Он здесь вот раз, два, три прошел, все, достаточно. Ну вот, немножко я эмоционально сейчас так.
26:21
А пример вот этот на полный экран модели, вот она здесь показана. Мы используем так называемый статус. На самом деле BP-Many изначально не предусмотрено нормальное качественное отображение движения данных, то есть нотация не про это. А нам это надо, поэтому в бизнес-студии есть возможность, кстати, некоторые справочники использовать похитрыми. Например, здесь вот исходящая карточка договора.
26:50
статус проект, второй статус подписан контрагентом, соответственно здесь вот идет 1sdo лежит или здесь вот например договор статус подписан компании, ну это компания, которую тогда проектный офис запускали, подписан контрагентом сканд в pdf и он попадает в 1sdo и через 1sdo попадает вот на следующий этап. То есть вот за счет этих статусов мы в бизнес-студии коллеги показываем всю эту историю.
27:20
В общем, подводя итоги, вот этот слайд был ключевой. В чем разница между хорошим и плохим IT? Хороший IT понимает ценность модели BPMN и как некий интеллектуальный актив компании, как некий мостик между бизнесом и IT, позволяющим говорить на одном языке, понимать, как процессы выполняются. Он ориентирован на…
27:47
развить этих процессов и их цифровизацию, реальное повышение их эффективности плохому IT BPMN не нужен, это для него просто дополнительная абуза отвлекающая его на обсуждение каких-то ненужных моментов, вместо того чтобы запускать штатные коробочные решения в работу значит вот примерно такую историю я хотел вам сегодня рассказать что хочу, коллеги, пользуясь случаем буквально там две секунды
28:13
У меня на этой страничке вы сможете потом посмотреть расписание моих трейдинга. В феврале будет трейдинг открытый очной по внедрению системы управления процессами. По Business Studio будет дистанционный трейдинг выйдя вебинара в феврале. И вот в марте стартует очень любопытный открытый очный трейдинг по анализу оптимизации. Так что если эта тема интересует вас или ваших коллег, руководителей, ну, пожалуйста, смотрите, заходите, обращайтесь.
28:40
Ну и специальное предложение для вас сегодня, если заинтересовала, если вы не пользуетесь системой бизнес студия 6, есть прекрасная возможность получить три лицензии конкурентных на срок три месяца бесплатно для тестирования или выполнения какого-то проекта по промокоду, которую здесь представлен. UDP Repin240125. Заполнить очень просто.
29:06
Но коллегия этот самый код действует до 1 марта, значит соответственно можно отправлять заявку на мою почту Я готов там сделать небольшие консультации по системе там если нужно Ну и в любом случае вот три лицензии бизнес студии вы можете получить совершенно бесплатно на три месяца с полно функциональных Закончить хочу своим фирменным слоганом, значит если хочешь перемен Изучая BPMN там, ну вот можно еще бизнес студия подозвучать если у вас его нет
29:35
Оважаемые коллеги, здесь мои контакты, все есть на этом слайде. Я думаю, презентация будет доступна, там какие-то вопросы или что-то можно всегда обращаться. Я тогда возвращаюсь, вот, наверное, сейчас я это дело удалю и соответственно вернусь вот на слайде к сравнению, точка зрения IT, готов ответить на ваши вопросы. Единственное, что я попросил бы Игоря немножко мне поассистировать, потому что я
30:03
когда я вижу презентацию, я одновременно не могу посмотреть на вопрос в чате. Это недостаток этой системы, на самом деле. Ну, про недостаток системы они все глючные. Каждое обновление – это для меня супер-стресс, но контур умеет в рефлексию. Это, кстати, про культуру, но это отдельный разговор, как-нибудь в другой вопрос. Сейчас, во-первых, благодарю, Владимир Владимирович, за этим, собственно, я и позвал…
30:33
угадал главный нерв, главную боль и главный запрос. Если можно, я вывалю все вопросы сразу, а вы уже балансируете временем, которые у вас есть на вопросы. Ну, я если сейчас могу выключить, допустим, демонстрацию, и тогда я могу их сам посмотреть. Вот сейчас я тоже. Часть вопросов не вся эта, это тут не вперемешка. Так, какую low-code-систему можно сейчас использовать в РФ как коммерческую, так и фревар?
31:00
А все, можно не зачитывать, я сейчас вижу. Спасибо большое. Ну, смотрите, ну, как бы... Ну, во-первых, как бы лидер рынка это ELMA. Потом идет, наверное, CommandWire, BPMsoft. Вот если вы можете открыть какую-нибудь дочку в Китае, то я знаю, что люди и без ADGE'а до сих пор продолжают использовать, покупая ее на китайскую дочку, но процессы запускаю в России. Они же там не отслеживают, где этот трафик проходит.
31:31
Коммунда, RunoWFH, ну и так далее. Так, всё, это один единственный вопрос. Нет, сейчас начинается часть для мастеров. Такой вопрос. Если можно все списком, а вы приоритеты расставляете. В каких-то случаях нам надо BPMN, а в каких-то не надо. То есть для крупных компаний это обязательно, потому что один рисует, процесс другой продолжает.
31:56
кто-то автоматизирует, кто-то будет через полгода рефлексировать, и у нас даже соглашение о моделировании становится самым важным документом. Не сам BPME, но он не покрывает всех потребностей. Соглашение о моделировании — это ключ. А в каких-то случаях нам надо на небольшом предприятии, где нет вот этой процессной культуры, говорить на языке цеха и писать инструкции от себя, описывать процессы понятными словами и показывать их на пальцах, как говорят. И вот этот баланс.
32:26
Потом очень важный вопрос, что тренд о том, что 1С всех приучил идти от документа, а производственные системы идут от события. Я сам сторонник этого тренда, я рад, что он развивается. В том числе мы говорили только что про вот эти вот бегунки в ЭЛМе. И вот идти от события или от документа. А можно тогда, я просто боюсь забыть, вот первый вопрос.
32:51
Первая группа вопросов, в принципе вы сами же уже о себе ответили, все правильно говорите, что нужно идти... BPMN это не инструмент допустим наладчик или рабочего цеху, ему это не надо. Это инструмент инженера, инструмент специалиста, инструмент руководителя подразделения. Допустим, когда вы процессы отладили кроссфункциональный, допустим, работы в том же цехе, там передача смена суточного задания, там еще что-то еще что-то отладили,
33:21
крупным шрифтом напечатанных каких-то маршрутных карт. Это не их BPMN, это не для них. Вы совершенно правильно говорите, что в цех надо идти с другими документами. А начальнику цеха, который организует процессы, в том числе планирование оперативное, выдача заданий, можно идти с BPMN, это менеджерская позиция. По поводу того, что Один Эс приучил, в Один Эс до сих пор даже нет конструктора процессов.
33:50
соответствия с международными стандартами. Но нету там никакого BPMN. Они крупные, большие, у них куча агентов, их настройщиков. Понятно, что им это не особо надо. Бизнес хорошо идет, но зачем им это нужно делать? Но мне кажется, что это не кастомизированные вещи. Они такие. Феодальный был у вас абзац, IT и процессный офис. Там нет еще двух феодалов.
34:19
директора по развитию и проектного офиса. Есть ли методы балансирования всех этих людей? А еще бывает отдельно бережливое производство, и каждый на себя тянет это диал, а каждый указывает, как надо трансформировать и так дальше, как надо строить процессы, откуда начинать и куда преднаправлять ресурсы. Балансировать эти феодальные разборки, есть метода, инструмент? Есть метода, да. Они обычно плохо дружат. Я наблюдал ситуацию крупных компаний, когда СМК.
34:49
откровенно воевало с процессным офисом, кто из них главный, это конечно для компании очень плохо. Моя точка зрения это подведение, допустим, бережливцев процессного офиса и проектного офиса подъедет под одного ЗГД по оптимизации процессов операционной эффективности. Но это должен быть достаточно серьезная фигура. Я такие ситуации в компаниях встречал.
35:15
тогда можно их между собой поженить, наладить, чтобы они между собой договорились. То есть должен быть руководитель, который их помирит между собой и заставит их работать вместе. Если они под разными ЗГД в разных функциональных колодцах, там войнушка обеспечена за редким исключением, если они смогли договориться. Административное подчинение одному руководителю. Я думаю, это единственное, что может их спасти в этой ситуации.
35:42
А какой-то собрать между ними мета язык или какие-то правила взаимодействия, такое что-то существует? Ну а зачем нам специальный язык создавать? То есть у нас для кроссфункциональных процессов, которые мы хотим автоматизировать административных, это BPMAN и этого достаточно, а для производства и размещения оборудования там, да, и оптимизации производственных потоков, там другие работают инструменты. Я имею в виду язык не в смысле буквальном.
36:09
а в смысле как в приличном казино, что все разборки только за забором, что у нас говорят по очереди, что у нас есть регулярные, допустим, рефлексии, что у нас есть разделение владельцев, что у нас, допустим, проект, если выделяется в отдельный проект, то там уже рулит менеджер проекта, а проектный офис может на него только стучать, а указывать ему уже не может. И это является вмешательством там.
36:37
страшные нарушения, вот такие вот вещи методически, организационно? Нет, ну вот тут как бы, смотрите, всегда хочется простых ответов на сложные вопросы, здесь так не проходит, то есть компании все, во-первых, а они все разного типа, но в этом плане я всегда как бы применяю вот эту классификацию ЛАЛУ, нет ничего лучше хорошей теории, ЛАЛУ нормально это все классифицировал, и я понимаю в какую организацию я захожу, красную, там, оранжевую и так далее.
37:06
Второй я понимаю на каком этапе жизненного цикла находится. И что это за организация? Допустим, если вы заходите в какую-то госструктуру жесткой эрахии и политики и так далее, ну там определенная группа методов работает. Если вы заходите в компания гибко развивающаяся, динамичную, типа Банька. и еще какие-то такие вот компании, где хорошая корпоративная культура, там другие методы работают. То есть вы сейчас вот сказали то ли и не то, там отношение все так...
37:35
Это же вопрос о уровне зрелости компании, ее типы, корпоративной культуры, которые выстроил менеджмент. И тут нельзя ответить однозначно на вопрос, что для одной компании вот это, для другой вот это. Понимаете, она зависит очень сильно от конкретной компании, ее состояние, ее типа, ее уровня развития, корпоративной культуры. Вот такая история. Вот у нас куда-то поднята рука, вопрос давайте быстренько.
38:05
Мое починение, Александр Борисович, давайте Орепина послушать. У меня просто большой-большой опыт, я с Владимиром абсолютно согласен. Сильно зависит от фактуры компании, от его ландшафта и от починения. Когда мы работали в корпорации, в государственном концерте, в «Ангалашнике ФОСК», там очень сильно было починение, ну, турной. Брали людей на работу, которые что-то говорят, знают. Но как только бизнес начинает замыкаться на маленьких процессах внутри себя,
38:35
начинают считаться деньги не в центре, а здесь, то возникает то, что мы начинаем рисовать процессы, они становятся эффективными. Каждый из этих ролей, которые находятся в СМК или в офисе управления проектами, проявляет в себе и хотят в себе увеличение зарплаты и хорошей жизни. Начинается у них вот грызняло именно с этого. То есть каждый пытается себя за счет чужих побед проявить. Вот это сто раз это было, это было причем не на одной и той же площадке, но это то есть обсуждали.
39:04
И жесткое подчинение под одной из структур, под одного зама. То есть тогда он палкой бьет по голове и они начинают работать. Это вот это вот железно. Потому что все зависит от типа компании. Это сто процентов что-то так. В Бирюзовая мне не посчастилось работать в Красных. Я уже по боковам много. А по-моему их и нет особо в Бирюзовых. Даже Кусфил вроде как говорят. Вот Бирюзовый, Бирюзовый. Да. А по части...
39:32
Бизнес-студио три года сидели рисовали, на самом деле штука великолепна, но мне повезло больше, у меня 4 айтишника были информационной системы в экономике и их учили этому в институте. Они пришли с этим знанием и результат был очень-очень хороший, колоссальный. Вот ребята, за это я вас и люблю, потому что я тут кровью подпишусь, но когда мне постараются поколотить, у меня есть видосик, я говорю
40:02
выдвинул эту гипотезу, потому что людям больно изменять картину мира. И на самом деле, когда были процессы отрисованы, ну скажем так, процентов на 80, основные были все точно, даже изменение процессов IT вносило изменения, потому что бизнес-студия у нас кончилась успешно, но мы их экспортировали, то есть рисовали. Нам не повезло, у нас как бы ротация персонала была наверху очень большая и сейчас идет.
40:31
где я раньше работал, я сегодня буду рассказывать об этом. Поэтому, когда они приходили в судостроение, они осел на картину Ван Гога, смотрели и не понимали, что вообще происходит. Машиностроение-то не ложится никак. А тут они хотя бы в предметную область погружались, грубо говоря, за два месяца. То есть они видели схему процесса, мы им это объясняли, как Василий Иванович, на картошке и луке, здесь белая, здесь наша. И как-то все было проще.
41:00
Давайте Владимир Владимировичу дадим возможность прокомментировать, то он сейчас убежит. Спасибо. И благодарю, Александр Борисович. Покомментируйте, пожалуйста, и в том числе вот тут вопрос. Баланс внешней и внутренней экспертизы сразу возникает, потому что в основном народ тоже впадает в крайность. То есть либо сделано у нас, либо сделано не у нас, либо мы все сами, либо вопросу сейчас придут люди, вы, короче, идите там на латте, а потом позовете, когда будете все готовы. То есть вот этот вот...
41:29
внутренней внешней экспертизы? Ну все зависит от того, кого удалось взять процессный офис. Если грубо говоря там нашли процессный офис человека, который это уже 10 раз делал в других компаниях, причем хорошем уровне, то понятно, что можно внешние какие-то, никого не звать. А если поручили человеку, который до этого никогда этим не занимался, то есть ни процессную архитектуру не проектировал, ни гроссфонциональные процессы не выделял.
41:59
Даже BP-MAN не знает. Ну понятно, что пока он будет это изучать, он там, во-первых, это дольше гораздо, во-вторых, ему тяжело очень будет. Он же под прессом, вот допустим, он приходит к уводителю какого-то управления и тот ему начинает рассказывать, как процесс идет. Опытный человек скажет, ну извините там, Мария Ивановна, вы мне тут рассказываете там про работу вашего подразделения, а мне нужно про кроссфункциональный процесс.
42:24
давайте вот это рамки вот такие установим такие границы проведем тогда и так далее и внешне человек он как бы он не подвержен этому прессу то особо он может сказать не извините это не так вот и ваш точка зрения неправильная давайте вот смотрите вот вот вот почему лучше сделать вот так да а внутренне он под прессами ему тяжело а если у него опыта нет то его просто сожрут и заставят его но до анекдота доходила что к водителю заставляли
42:52
переделывать BPMN под себя. Вот им не нравится здесь значок? Нет, будем теперь думать, что это вот так. И они меняли даже вплоть до того, что соглашение по моделированию под руководителя верхнего уровня. Что вообще говоря, очень дико смотрится со стороны, как международный стандарт взяли и поменяли под себя. Поэтому внешний он быстрее может дать, опять же, при условии, чтобы взяли квалифицированного внешнего подрядчика на эти работы. В данном случае мы говорим о чем. Это проектирование архитектуры,
43:21
предприятие, это проектирование анализа ключевых кроссфункциональных процессов BPMN это создание вот этой вот модели компетенции и создание неких компетенций у руководителей подразделения, умения работать с этим инструментом и методом. Внешне просто это сделает быстрее. Внутренним путем само обучение если вот как предыдущий коллега сказал, что ему повезло, у них 3 человека, которые учили в институте все это делали, или 4
43:50
Это было бы здорово. Я знаю, что есть такие у нас институты. Вот в Москве Миссис, например, Первый наци университет, там кафедра Петецка, Валерий Ефимович, они там ребята очень серьезно прокачивают и по нотациям, по BPMN, по современным продуктам. Да, такой человек, если приходит парень молодой, конечно, круто, вот он уже все это знает. И опыт у него же есть. Конечно, это повезло такого найти на рынке. А если не нашли такого? Вот приходит у нас тоже был случай,
44:20
Всю жизнь занималась СМК, БПМН не знает, бизнес-студия не знает, вот рисовала диаграмма с ромбиками, ну вот, вариант какой? Только учить. Вот не все люди в таком возрасте обучаемы, к сожалению. Ну, это отдельный вопрос про эйджизм, я как бы к этому уже не то что привык, я это превратил в доходы.
44:44
Меня списали еще по возвращению из Дьетнама в 14 году, 10 лет назад. Мне уже сказали, что мне нет места войти. Ну мы-то все бодренькие такие, да, с вами, да? Есть еще и вопрос, и запрос, и предложение. Давидча разговаривал с общим знакомым, он сказал фразу, говорит, у Репина синдром отличника. И это был самый лучший комплимент в данном случае.
45:13
Потому что, о чем я хочу попросить и может вкратце покомментировать. Иногда нам нужен китайский подход, что давай шевелиться быстрее. Ну такси, курьеры. Иногда нам нужен русский подход, что мы как привыкли все проспать, зиму на печи, а потом бросаться на абразуру и проявлять героизм петилетку за три дня. Иногда нам нужен немецкий подход. То есть о чем речь?
45:41
что эту тему поднял талип, и она неожиданно оказывается развивается серьезными исследованиями, что маленькие косяки приводят к большим проблемам, что когда мы игнорируем в системе маленькие отклонения, может привести к затрате больших ресурсов и к тому, что мы можем потерять устойчивость системы. Вот этот вопрос, то есть если можно сейчас прокомментировать, а вообще глобально, если бы нашлось время эту тему обсудить,
46:07
устойчивости систем. Не просто вопрос, что, ребята, ну мы же видим, что тут все криво, давайте все делать как-то лучше, давайте валидировать, давайте что-то перепоручим роботам РПА. Именно то, что люди очень часто строят неустойчивую систему, то есть вот городят, городят, особенно IT сейчас, почему рушится отрасль. Потому что вот эта гора костылей смотанная на скотч из говна и палок в большинстве случаев уже рушится. Не то что
46:37
есть ли какие-то методики анализа устойчивости, вот этот малых отклонений, какие-то с ними работы. Вообще-то важная история и можно ли ее проработать. Безусловно, эта история важная. Вот и, допустим, когда мы в работе, в рамках работы рабочих групп, там, да, проектируем новый процесс, то обязательно надо его проверять с точки зрения тех рисков, которые могут возникать при его внедрении и работе.
47:06
соответственно как минимум оценивать не хуже ли мы сделали в том числе вот с точки зрения устойчивости воздействия измучающих факторов вот но к сожалению это обод далеко делают не все потому что во-первых от нужной методику нормально делать вторых надо тратить время и если допустим крупная какой-то банк или какая-то крупная компания телеком какой-то да имеет там
47:31
тестовые сервера и допустим какое-то решение, новое изменение сначала гоняет на тестовых серверах причем ставят даже эти сервера буквально там выкупают старое оборудование, которое до сих пор еще стоит аналоги в отделениях, на них тестируют нагрузочные тестирования, все это делает. Это в каком-то степени минимизирует вот этот фактор то другие компании, у которых такого ресурса нет, как у крупных банков или телеком, они это себе позволить не могут, например
48:01
им нужно сразу это все как-то внедрять. Это, конечно, порождает риск. Что касается Толеба, классно, мне вот очень нравится его книжка «Рискую собственной шкурой». То есть мое понимание вот этих вот хрупких систем, выстроенных, заложенные уже недостатками невозможности реагировать на взмучающие воздействия, это как раз отсутствие ответственности руководящей состава. Ответственность это, как мне один юрист корпоративно объяснил, мне очень нравится. Это ущемление прав человека.
48:30
что такое ущемление прав? Это расстрел, посадка, лишение квартальной премии, увольнение, моральное проециание коллективом, выговоры занесением и муки совести ночью. Вот если человек совершил что-то, какое-то действие внутри работы в компании, которое повлекло за собой негативные последствия, но при этом вот это вот ущемление прав не наступило, то это означает, что ответственности нет. Вот о чем Толеб пишет, что шкура-то не пострадала от слова совсем.
48:58
Это означает, что мы можем строить любые системы, хрупкие там, вот эти системы, неустойчивые. Но завтра человек из компании ушел и ему фиолетово. То есть ключевой момент, как мне показалось, Олебо, это, что нужно на самом деле создавать систему ответственности за проектирование вот таких вот организационных систем. Ну прямо вот я услышал цитату Джордана Питерсона трехлетней давности.
49:24
Чуть ни слова в слово. Если будет время и вдохновение, то эту тему обсудить бы. Потому что очень часто я вижу, когда люди сами строят себе гильотину за свои деньги или сами, грубо говоря, ведут подков под свою организацию. Мы увидели своего врага, и он есть мы. Кстати, мы выбираем фразу года, можете свои варианты предложить. У меня в лидерах цитата талиба годичной давности...
49:51
вашу компанию уничтожить не конкурент, а вашей чарш-службой. Ну, я могу предложить вариант, если хотите загубить бизнес, доверьте его управлению об эклтерам. Это Форд сказал. Это кто сказал? Форд, Генри Форд. Да, это очень актуально. Кстати, по статистике CDT-O самый большой процент это выходцы из финансистов. Так что это отдельная тема, как-нибудь отсугем. Большое спасибо, благодарю. Вам спасибо, что пригласили. Коллеги, хорошего дня.
50:21
Спасибо, всего доброго, спасибо большое.
