Оригинал: Business Process Management In A Post-GPT World
Автор: Ян Готтс (Ian Gotts), основатель и генеральный директор Elements.cloud
Свою первую процессную диаграмму я нарисовал более 35 лет назад, когда начинал работать в Accenture. Я использовал нотацию IDEF0 для описания требований к ERP-системе, которую мы внедряли у одного из военных подрядчиков в Британии. Мы использовали диаграмму процесса для проверки настроек системы, которые заказчик хотел реализовать с нашей помощью. Принципы IDEF0 вдохновили на создание UPN (universal process notation — универсальная процессная нотация).
Вернемся в день сегодняшний. Валидация требований по-прежнему остается наиболее полезным применением схем процессов. Они обеспечивают взаимопонимание между всеми заинтересованными сторонами и позволяют полностью воспринять потребности бизнеса. Кроме того, схемы процессов приносят пользу в обучении персонала и в разработке нормативных документов.
Карты процессов UPN используют многие организации, но наиболее широко процессный подход применяется в отраслях с сильным регулированием – пищевой, фармацевтической, финансовой, нефегазовой – где отсутствие или несоблюдение процессной документации наказывается штрафами.
Проблемы внедрения схем процессов
Несмотря на очевидную пользу схем процессов, они не получили широкого распространения. Процессное сообщество не позаботилось о том, чтобы стать более востребованным для бизнеса. Фактически, процессная практика эволюционирует в направлении от бизнеса, становясь все более самоизолированной. Вот некоторые примеры:
- Длительные проекты реинжиниринга бизнес-процессов приводят к куче непонятных схем, которые понимают только их авторы.
- Нотации UML и BPMN слишком сложны – они включают более 300 элементов, которые способны понять только BPM системы, которые генерируют из них бизнес-приложения.
- Требования к подготовке по различным уровням (поясам) шести сигм требуют огромных инвестиций и по-видимому недостижимы для большинства людей.
Стандарт UPN воспринимался некоторыми представителями процессного сообщества как слишком упрощенный, процессных специалистов он не привлекает. Однако при более внимательном рассмотрении UPN – это больше, чем просто квадратики и линии. Самое главное, UPN разработан для привлечения заинтересованных сторон, поскольку его с легкостью понимают сотрудники на всех уровнях иерархии и из любых подразделений.
Это особенно важно сейчас, когда многие корпоративные приложения (например, Salesforce, ServiceNow и Workday) конфигурируются с помощью метаданных. Они также могут работать с решениями третьих сторон, такими как Boomi или Zapier, и в них легко можно настроить интеграцию. Это означает, что внедрение стало сильно ориентировано на бизнес и на «Low-code», а не на «Pro-code» – заказные ИТ-центричные разработки.
В будущем бизнес-аналитики будут использовать такие методы картирования процессов, как UPN, для активного вовлечения бизнес-пользователей. С помощью схем процессов можно будет валидировать требования и описывать пользовательские сценарии. В свою очередь, пользовательские сценарии будут описывать требуемые изменения в настройках, которые реализуются через метаданные, а не программированием на заказ.
Роль ИИ/GPT в картировании процессов
Уже понятно, что в течение плюс-минус пяти лет искусственный интеллект/GPT научится писать код и настраивать приложения. Но на что ИИ (пока) не способен – это понять, что нужно бизнес-пользователям. Это обязанность бизнес-аналитика. Благодаря ИИ/GPT бизнес-аналитики смогут существенно повысить производительность своей работы. Мы уже наблюдаем это у консультантов и у наших клиентов.
ИИ/GPT может взять текст, полученный расшифровкой диалога с бизнес-пользователем, или нарисованный эскиз, скомбинировать их с лучшими практиками из своей модели и составить диаграмму UPN. Это экономит время и включает людей в работу, когда они видят еще только пустой экран.
Навыки бизнес-аналитика здесь являются ключевыми: задать вопросы, полученные ответы дать на вход ИИ/GPT, проверить полученный результат и доработать. По нашему опыту, ИИ/GPT рисует неправильную диаграмму только если информация на входе была неполной или неоднозначной.
Кроме процессной диаграммы AI/GPT может создать пользовательские сценарии с программами испытаний. Это не только снижает трудозатраты, но и делает пользовательские сценарии более последовательными и точными. По результатам бизнес-анализа затем к ним можно вернуться и доработать.
По нашему опыту, проблемы с пользовательскими сценариями обычно возникают из-за неточности или неоднозначности в схеме процесса. Поэтому лучше сначала исправить схему процесса, а затем с помощью ИИ переписать пользовательский сценарий. Раньше, до появления ИИ/GPT, мы дорабатывали пользовательские сценарии, но зачастую при этом мы не возвращались к картам процессов, которые из-за этого могли становиться неактуальными.
Теперь, с приходом ИИ/GPT, мы вынуждены вносить правки в базовую документацию, так как все генерируется из нее. Актуализация документации является ключевым фактором, который обуславливает наблюдаемое существенное повышение производительности.
Есть и еще преимущества. Вместо программирования, корпоративные приложения теперь конфигурируются посредством метаданных. ИИ/GPT может рассмотреть каждый пункт программы испытаний каждого пользовательского сценария и оценить, поддерживают ли его имеющиеся метаданные. Если нет, ИИ/GPT предлагает доработки. Это экономит время и уменьшает технический долг. Аналитик не в состоянии просмотреть тысячи элементов конфигурационных метаданных и оценить каждый из них для каждого пункта программы испытаний. ИИ/GPT требуется вся имеющаяся информация о метаданных.
Будущее BPM
Будущее BPM внушает оптимизм. Однако ему необходимо развиваться и сосредоточиться на создании базовой документации (карты процессов, диаграммы «сущность-связь», описания метаданных), которую ИИ/GPT сможет использовать для ускорения последующих этапов разработки приложений. Навыки бизнес-анализа останутся востребованными на этапах создания и валидации этого контента.
Благодаря способности читать документацию на естественном языке, ИИ/GPT сможет предлагать изменения конфигурации, а в будущем – создавать и настраивать приложения. Это приближает нас к реализации идеи, вдохновлявшей развитие BPM на протяжении последних 20 лет: создание приложений из схем процессов. Это становится возможным благодаря тому, что компьютеры теперь способны понимать общедоступные схемы процессов, вместо основанных на псевдокоде диаграмм, понятных только их автору и компьютеру.
Наконец-то мы преодолели кремниево-углеродный барьер.
Обсудить