Анатолий Белайчук, Comindware – о том, как BPM превращается в интеллектуальную автоматизацию

Анатолий Белайчук: Я смотрю на эту ситуацию более широко. Low-code – это всего лишь один из маркетинговых лейблов. Есть теория протоколов общения: иерархический («я начальник – ты дурак»), научный («как было доказано в предыдущей лемме…») и есть метафорический протокол. Так вот, маркетинг работает в метафорическом протоколе, он всегда вбрасывает в обиход новые понятия. Хороший маркетинг, кстати, – это всегда поэзия, и к ней нельзя подходить с упрощенными мерками: хорошо или плохо. В этом смысле, когда мы говорим про low-code, надо понимать, что мы выделяем одну из граней достаточно большого явления.

Анатолий Белайчук: Посмотрите на предыдущие «лейблы», например, идею, так называемых, двухскоростных или многоскоростных ИТ (Dual/MultiSpeed IT), которую также придумали аналитики Gartner. Эта идея была очень свежей в 2010 году, когда парни из Acronis основали компанию Comindware и мы изучали, куда движется рынок. Или более свежую идею Citizen development - «гражданской» разработки, которая ведется не-ИТ-специалистами. Все они говорят об одном – о том, что необходимо разделить ИТ на части, например, отделить фундаментальные вещи от высокоуровневых прикладных. Более того, рискну предположить, что такой подход к разработке ИТ присутствует уже лет 25, как минимум. По крайней мере, с того момента, когда предприятия начали внедрять ERP-системы: вначале нужно создать фундамент, а уже потом заниматься трансформацией бизнес-процессов.

Анатолий Белайчук: Да, свежая этикетка для вечной идеи. Что касается BPMS, то здесь история еще интереснее. Если сам термин «low-code» ввели в обиход аналитики Forrester лет 7 назад, то системы BPM изначально были low-code. Тогда это называлось Model Driven Development — модельно-ориентированный подход к разработке программного обеспечения. Суть этого подхода состоит в построении абстрактной метамодели управления и обмена метаданными (моделями) и задании способов ее трансформации в поддерживаемые технологии программирования (Java, CORBA, XML и др.).

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

Анатолий Белайчук: Роль ИТ меняется. На предприятиях ИТ-департамент – это уже не затратный обслуживающий персонал. Цифровая трансформация возлагает на ИТ особую миссию - создавать новые модели бизнеса. Назовите это историческим шансом или вызовом, суть от этого не меняется. Проблема в том, что бизнес пока не видит признаков того, чтобы ИТ в массовом порядке стремились соответствовать этой новой роли.

Дело в том, что у каждой из сторон – своя правда. Люди из бизнеса мечтают увидеть айтишников, которые будут помогать развивать бизнес. А те уверены, что их работа строится по правилу «Пусть бизнес четко скажет, что им нужно, мы им все автоматизируем». Но жизнь не так устроена! Нет возможности четко прописать бизнес-задачу для ИТ. И нет возможности ждать несколько месяцев, пока «все автоматизируют».

Анатолий Белайчук: Это одна из составляющих. На самом деле у бизнеса внутри – те же самые проблемы кросс-функционального взаимодействия. И вся процессная тематика вокруг этого крутится. Всем известны вечные проблемы: как операционный блок научить работать с продажниками, а производственников с финансистами? У них постоянное недовольство друг другом, а, между тем, им надо сообща работать на общую цель. Но барьер между ИТ и бизнесом, на мой взгляд, еще выше, потому что в ИТ работают специфические люди, зачастую почти аутисты, которым комфортно сидеть в рамках своего уютного контура технологий.

Анатолий Белайчук: Не совсем. Это другой тренд – объективная тенденция расширения фронта работ, связанных с информатизацией, потому что не найти столько профессиональных программистов, сколько требуется. И поэтому я считаю, что оценки агентства Gartner соответствуют действительности. По той же самой причине, по которой изменилась профессия водителя, а профессия машинистки в машбюро исчезла вовсе, - теперь все стали водителями и машинистками.

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

Анатолий Белайчук: С этим как раз нет проблем. Программисты делают хорошо солидную, основательную разработку, скажем, единую базу данных, которая будет универсальной и сможет поддерживать любые процессы. А вот переписывать сценарии процессов – это же скука невообразимая, правда? Нормальный программист один раз такую работу сделает, второй, а на третий напишет заявление об увольнении, потому что каждый программист в душе – ваятель прекрасных ИТ-творений, а не исполнитель рутинных мелких работ.

И вот здесь появляется место для low-code платформ, таких как Comindware Business Application Platform. По сути, это еще одно звено на верхушке корпоративного стека технологий. Там уже «зашиты» определенные правила работы с данными, например, если мышкой передвинуть квадратик в схеме процесса и переместить стрелочку, то тем самым добавится шаг согласования.

Анатолий Белайчук: Есть такая экспертная концепция – о цикличности в разработке ИТ. Вкратце ее смысл в том, что когда появляется новая информационная технология, то вначале это поле деятельности самых крутых программистов. Если это по-настоящему новая технология – та, которая в англоязычных текстах называется disruptive, то есть подрывная, та, которая делает технологию предыдущего поколения неактуальной. В самом начале новая технология доступна только «высоколобым», но с этого же момента возникает движение в направлении упрощения ее использования, стремление сделать ее доступной для тех самых «обезьян», которых Вы упомянули ранее. Low-code появляется тогда, когда high-code перестает быть передовым краем технологического прогресса.

Анатолий Белайчук: Вспомним для начала, с чего начиналась цифровая трансформация. Эта аббревиатура сегодня уже основательно подзабыта - SMAC (Social, Mobility, Analytics, Cloud). То есть соцсети, смартфоны (мобильный доступ), аналитика (большие данные) и облачный сервис. Идея – отличная: вот тебе смартфон, а за ним в облаках – огромные сервера, которые доставляют тебе все мыслимые блага информационного общества. Этот круг технологий, действительно, составляет нечто цельное с очень мощной синергией. Смартфон без облачных сервисов – это старая добрая звонилка и калькулятор. А если за ним находятся мощные сервера, на которых крутятся сервисы типа Яндекс.Такси, - это принципиально иной уровень развития ИТ.

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

Анатолий Белайчук: Да, меняет. С одной стороны, происходят изменения на уровне лейблов. Где-то год назад компания Forrester предложила новый лейбл: DPA (Digital Process Automation). Не путайте RPA (Robotic Process Automation) – это совсем другое. Причем, ввели два типа терминов: DPA Wide и DPA Deep.

С другой стороны, есть более глубокие изменения. По сути, на смену термину BPMS приходит понятие интеллектуальной автоматизации, которая вбирает в себя весь предыдущий опыт, включая, собственно, BPMS, а также low-code, RPA, машинное обучение и прочие унифицированные коммуникации. Но есть проблема.

Наличие двух типов систем: DPA Wide и DPA Deep,- говорит о том, что на новом уровне сохраняется то деление на два типа систем, которое было свойственно системам BPM от рождения: одни - про взаимодействие технологических систем (System-to-System BPMS), другие – про взаимодействие людей (Human-to-Human BPMS). Это системы с разными корнями и заточенные под разные процессы.

С одной стороны, это продукты таких компаний, как Appian и BizAgi. Они акцентируют внимание на бизнес-процессах, которые соединяют людей. Их парадигма: BPM – это то, что делают люди. С другой стороны – системы таких компаний, как IBM и Oracle. Они описывают бизнес-процессы в парадигме оркестровки сервисов. Почувствуйте разницу! Бизнес-процессы – это то, что делают люди, или это оркестровка сервисов?

Так вот. Это вечное деление одной сферы ИТ на два класса сегодня получило новое название: DPA Deep и DPA Wide.

Анатолий Белайчук: По сути, есть два типа процессов. У любой организации есть, образно говоря, «производство» и «заводоуправление». Производственные процессы, которые протекают в «цеху», радикально отличаются от бизнес-процессов заводоуправления. В «производстве» существенную роль играют люди, которые работают на станках, и там возможности автоматизации объективно более ограничены, чем в заводоуправлении, где открываются гораздо более широкие возможности для цифровизации. Есть, правда, специфические отрасли – финансовый сектор, банки, страховые компании, у которых «цех» - весь цифровой.

Так вот, есть два класса BPMS, соответствующие этим двум типам процессов. Один класс – системы общего назначения, предназначенные для процессов, протекающих в офисе. В это разряд попадают системы DPA Wide, а также их предыдущая реинкарнация – Pure-Play BPMS. А второй класс – это специфические процессы, которые характерны для тех сегментов рынка, где можно реализовать полностью автоматический процесс. Яркий пример – нынешние банки.

Такой подход помогает лучше увидеть суть цифровой трансформации: традиционные бизнесы все более становятся похожими на банки, с точки зрения тех объемов «производственных» процессов, которые можно цифровизовать. Скажем, благодаря Интернету вещей материальное производство становится все более цифровым.

Анатолий Белайчук: Стандартного обозначения, к сожалению, нет. В качестве рабочих определений можно назвать их: бизнес-процессы и технологические («производственные») процессы.

Чем характерны «производственные» процессы? Их относительно немного, и у них бизнес-логика проще. Но зато у них очень высокая интенсивность. Представляете, какое количество финансовых транзакций совершается в единицу времени в системе Сбербанк-онлайн?

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

Это разные экологические ниши систем BPM: разные ИТ-решения, разные платформы и разные человеческие ресурсы. В случае технологических процессов профессионалы делают почти 100%, а в случае офисных бизнес-процессов – 10-25%. И им соответствуют разные виды типичных приложений: цифрового производства и цифрового бизнеса. Компания Comindware работает в массовом сегменте цифрового бизнеса.

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

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

Анатолий Белайчук: Вообще современные процессные технологии фокусируются, в первую очередь, на кросс-функциональном взаимодействии. Потому что любое разделение труда приводит к отсутствию взаимопонимания. Люди занимают оборону - каждый в своем департаменте - и «отстреливаются» от попыток всех остальных навязать им «не мою работу». И у каждого – свое понимание, за что ему платят зарплату. Поговорите с бухгалтерией на одном, другом, третьем предприятии, и вы услышите: «Для нас главное, что по журналу все сходится». А за результат в целом кто отвечает? За то, насколько при этом будет счастлив заказчик?

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

Все это очень жестко завязано на клиентоориентированность и на то, что отличный результат для клиента – это следствие общей работы разных служб, а не одного конкретного подразделения. Это радикально меняет саму корпоративную культуру. И в этом, в том числе, помогает система BPMS типа нашей Comindware Business Application Platform, в основу которой положена идея процессного движка: как нарисовали схему, так это и работает в жизни.

Анатолий Белайчук: BPMS полностью решает типичную проблем ответственности: системе всегда известно, на кого переведена стрелка. Как только я нажал кнопочку «Готово», в тот же момент у плановиков появилась их задача, и будильник начал тикать. И соответствующий владелец процесса, руководитель может зайти на портал и объективно увидеть, на кого указывает стрелочка. Не по отчетам судить, не слушать препирательства служб, кто кому не предоставил данные, кто виноват. Вопросы ответственности и передачи ответственности наша ИТ-система решает, что называется, by design, то есть она так изначально создана.

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

Если говорить конкретно о методологии, то там ключевая вещь – связь со стратегией. Что такое, по сути, управление процессами? Это способ транслировать стратегию в операции. Из этой формулы дальше все выводится. То есть управление процессами прочно завязано на маркетинг, value proposition (ценностное предложение), сегментацию рынка, ценность для потребителя – фактически все вокруг нее крутится. А как проектировать процессы? Не надо проектировать процесс продажи, надо проектировать процесс покупки нашего предложения клиентом.

Соответствующая методологическая база - фундаментальная идея управления Деминга-Шухарта, цикл PDCA (Play – Do - Check – Act). Она и закладывает в управление процессом постоянное улучшение качества. По большому счету, система BPMS создается, исходя из задачи поддержки этого цикла PDCA.

Собственно, BPMS – это мощный инструмент именно потому, что он создан для поддержки правильной методологии. Буква P («Plan») в аббревиатуре PDCA обозначает все то, что связано с моделированием: рисование процессов, моделей данных, model driven или low-code. Причем, все это непосредственно с тесным вовлечением бизнеса, и это принципиально важно.

«Do» – процессный движок.

«Check» - всевозможные средства отчетности, большей частью графические, которые доступны в любой BPMS, как говорится, из коробки: диаграммы, механизм Drill-dawn – для того, чтобы видеть, как процесс существует на уровне экземпляра, кто тормозит процесс, а также статистика: каков процент успешных процессов, как это соотносится с нормативами, какие тренды развиваются и т.п.

«Act» - это просто волевой акт: владелец процесса принимает решение, что пора что-то изменять.

Анатолий Белайчук: Наш продукт поддерживает такой передовой тренд, как работа BPMS в браузере. К тому же у нас и среда разработки тоже реализована в браузере. Хочу подчеркнуть, что этот подход мы приняли еще до того, как это стало мейнстримом.

Мы считаем, что если говорить о полноценном механизме low-code, то инсталлировать что-то на свой компьютер – это рудимент из разряда уходящей натуры. Жизнь уже приучила пользователей получать ИТ-услуги буквально на скорости клика: подписался на сервис, получил акаунт, пароль и через пять минут уже можно рисовать свой процесс в браузере без всяких дополнительных действий и ожиданий.

Еще с самого начала у нас была заложена идея о поддержке разных форм работы: в одном продукте поддерживаются и формализованные процессы и менее формализованные. Плюс к этому мы объединили в одном продукте и исполнение процесса, и архитектурные вещи.

Анатолий Белайчук: Конечно. Показателен конкурс проектов BPM, который проходит ежегодно: он отчетливо демонстрирует, что до сих пор существует водораздел: есть проекты, связанные с внедрением BPMS, непосредственно с автоматизацией, а есть проекты разработки процессной архитектуры. Это разные проекты, которые используют разные инструменты. Скажем, для описаний процессов где-то ARIS используется, где-то Business Studio. И это беда! Потому на практике получается: красивая архитектура – здесь, а реальное исполнение процессов – вон там. Важно и то, и другое, но эти системы между собой плохо стыкуются.

Никакого рационального смысла в таком разделении нет, просто так исторически сложилось. Более того, держать две системы крайне неудобно, потому что расхождение между ними неизбежно. Должна быть одна система и общий список процессов. Часть из них существует в виде записей реестра с минимальным паспортом, например, кто ответственный. Другие процессы существуют в виде регламента: по шагам расписано, что делать. А для некоторых процессов регламент уже полностью автоматизирован: можно нажать на кнопку, запустить, и он побежит по службам, потащит за собой соответствующий контекст, то есть данные, появляющиеся на каждом шаге процесса. Это особенная «фишка» нашего продукта.

Анатолий Белайчук: Терминология «обезьяны с гранатой» мне лично не очень нравится, но такая проблематика, конечно, есть в реальности. И есть и ответ на поставленную проблему.

Хорошая low-code система имеет, по сути, два фасада. Один обращен к тем самым гражданским разработчикам – идите, «мышкуйте». И есть другой фасад, обращенный к профессионалам, которые определяют политику процессов и сами выполняют действия, например, по переносу ПО из среды разработки в промышленную. Знаете, пока эта «обезьяна» резвится в своей песочнице, нет никаких проблем. Вопрос в том, чтобы все, ею порожденное, аккуратно протестировать и контролируемо перенести в промышленную среду. Здесь важны средства мониторинга, параметры надежности ИТ-систем. И, что критически важно, - в этот момент происходит передача ответственности, ответственность за промышленную эксплуатацию должны взять на себя соответствующие службы ИТ.

И в этом отношении важно, что этот low-code не вызывает отторжения у ИТ, потому что в системе предусмотрены средства для решения соответствующих задач, например, контролируемый перенос low-code в production, валидация контроля качества и последующего мониторинга, как этот low-code ведет себя в эксплуатации и т.п.

Говоря об этом, не могу не сказать отдельное спасибо ИТ-специалистам «Сургутнефнегаза» - в ходе нескольких проектов они формулировали требования, которые нам очень помогли подтянуть свой продукт по ряду аспектов.

Анатолий Белайчук: Отвечу так: для ИТ-департамента - это возможность. Конечно, программистам придется поддержать эти процессы администрированием, возможно, некоторым обучением. Но взамен открывается возможность воспользоваться чужим ресурсом, предоставив этому ресурсу подходящий инструмент. Для ИТ-департамента low-code - это возможность умножить свою производительность кратно.

Анатолий Белайчук: Вспомните стандартную ситуацию: бизнес приходит к ИТ и говорит, что срочно требуется бизнес-приложение. На это ИТ отвечает: нет проблем, записываем вас в очередь, через 6 месяцев приступим. Теперь ситуация проигрывается по-другому – ИТ говорит: у вас в департаменте есть пара-тройка толковых сотрудников, мы дадим им инструмент, и они сами все быстро сделают.

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

Анатолий Белайчук: Отличный пример – проект в компании S7, точнее, ее «дочке», у которой основной бизнес – авиационные тренажеры. Это очень специфический бизнес. Во-первых, они продают слоты для тренировок, примерно, как в кинотеатре продаются кресла на определенный сеанс. Во-вторых, при этом они продают комплексную услугу: прилетает экипаж, нужно эффективно распорядиться теми 24 часами, которые у них есть до следующего рейса: доставить в гостиницу, заселить, накормить, обеспечить тренажерный комплекс с инструктажем и т.д., вплоть до культурной программы. Это ведь, между прочим, высококонкурентный глобальный рынок – экипаж может выбрать аналогичную услугу в другой стране.

И вот эту головоломную логику менеджер компании с помощью нашего инструмента реализует сам, собственными силами. Мы ему помогаем совсем немного – не более 20% работы, например, реализовать какие-то сложные интеграции. Представляете, во что бы это вылилось, если бы за такую работу взялся интегратор с классической методикой: обследованием, разработкой, тестированием и всем штатом участников проекта: аналитиками, архитекторами, разработчиками, тестировщиками и т.д.? Скорее всего, ничего бы вообще не получилось. А с нашей системой менеджер, который отлично знает бизнес изнутри, сам рисует бизнес-логику, делает нужные связки в ПО.

Анатолий Белайчук: Это правда. Дело в том, что такие инструменты востребованы там, где процессы специфические. Если речь идет о стандартных, рутинных процессах, тогда возьмите, к примеру, 1С. Этот продукт закрывает большую часть стандартных процессов и требует минимальной кастомизации. Действительно, зачем вам лучший в мире складской учет, если вы не оказываете профессиональные услуги складского хозяйства? Но вот если речь идет о том, что вы считаете своей ключевой компетенцией, как, например, услуги авиатренажеров профильного подразделения S7, значит, над процессами нужно вдумчиво работать, выжимать из них максимум возможного. И для этого наша система отлично подходит.

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

Причем, эта схема – не программный код, а нарисованная бизнес-сотрудником модель процессов. И она кардинально меняет корпоративную культуру: не надо ждать полгода, чтобы внести небольшое изменение, скажем, в SAP-систему. Я помню рассказ нашего партнера, компании КРОК: «Заказчик в шоке: мы приходим через три дня после того, как нам обрисовали задачу, а нас ждали не ранее, чем через три месяца».

Анатолий Белайчук: Есть расхожий рецепт, который, кстати, в рамках BPM существовал всегда. Звучит он так: действовать тактически, а мыслить стратегически. Вы спросите: а где же здесь связь с ИТ-платформой? Отвечу: мы со своей ИТ-системой замахиваемся на то, чтобы превратить стратегию в машинку, которая эту стратегию реализует.

Стратегия появляется уже на уровне ремесла. Скажем, я моделирую процесс, который является достаточно важным для компании, например, взаимодействие с заказчиком. Но я не могу сделать эту работу, пока мне не скажут, что для нас является приоритетом: качество, простота или экономия затрат? У меня разные будут схемы процесса в зависимости от того, что у компании в приоритете.

Но, знаете ли, парадокс ситуации заключается в том, что очень часто инструментами low-code для улучшения процессов начинают пользоваться для решения очень простых, почти тривиальных задач. Например, тема административно-хозяйственного обеспечения (АХО). Вот уж, казалось бы, где высокоумные стратегии, а где протекающий кран, который требует ремонта? Но сотрудник сам взял наш инструмент и сделал процесс обработки хозяйственной заявки. Простой процесс из пяти шагов, но для тысяч работников (это тоже было в «Сургутнефтегазе») их жизнь в рабочем пространстве реально улучшилась. Это пример классической разработки «гражданского» сотрудника.

Анатолий Белайчук: С одной стороны, есть объективная проблема: как вычленить из общих интегральных показателей бизнеса долю роста, приходящуюся на конкретную систему процессной обработки? Это объективно очень непросто. С другой стороны, приведу конкретный ответ одного нашего клиента, руководителя компании, которая занимается установкой пластиковых окон. Он сказал, что экономический эффект от внедрения, конечно, есть, но главный результат для него лежит гораздо глубже - радикально меняется культура компании. Меняется то, как люди себя ведут, как они взаимодействуют друг с другом, как они относятся к заказчику.

Я уверен, что искусство достигать новых вершин в бизнесе за счет эффективно организованных процессов заключается в том, чтобы одновременно видеть цели и краткосрочные и долгосрочные. Просто бросить все ресурсы на цифровую трансформацию – это может быть плохой идеей. Нужно и на тактическом уровне находить бизнес-эффекты и затыкать дыры неэффективности, через которые деньги утекают. И одновременно, аккумулировав ресурсы, увидеть более дальние цели. В целом, знаете, что вдохновляет во всей этой истории с развитием BPMS? С течением времени она впитывает новые и новые технологии: тут и RPA, и искусственный интеллект, и облака. Но остается неизменной глубинная первичная потребность бизнеса - необходимость сегодня работать лучше, чем вчера, а завтра лучше, чем сегодня. По большому счету, мы занимаемся не процессами, а повышением эффективности бизнеса по всем ее составляющим: результативности, клиентоориентированности, экономии затрат и т.д. Вам в любом случае придется этим заниматься. Можно авральным порядком, можно командно-административным, но все это работает до поры до времени. А если мы хотим наладить долговременный и основательный процесс развития бизнеса, придется пристально и вдумчиво заниматься процессами.

Вот, кстати, наблюдение еще одного из наших клиентов, сделанное на базе статистики Comindware Business Application Platform: те подразделения, которые больше всех возмущаются и саботируют систему, - это те, у которых исполнительская дисциплина очень низкая. Так что тем, кто продолжает сомневаться, не превратится ли «гражданский» разработчик в «обезьяну с гранатой», дам простой совет: вы начните в этом режиме работать, и только потом выставляйте оценки: нравится или не нравится. Тем более, что начать работать в таком формате сегодня очень просто.