← Предыдущая статья

Первая порция заметок была про крупные контуры: суверенитет, ERP, нагрузку, ИИ, ответственность, роль аналитика и жизнь после закупки. Там главным вопросом было: что отличает красивую декларацию от работающей корпоративной системы?

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

Продукт сам себя не применит.

Инструмент не объяснит заказчику его процесс. Кнопка не превратит хотелку в требование. Запись в реестре не докажет, что продукт закрывает живую задачу. Термин не станет общим только потому, что все его слышали. Профстандарт не успеет за ролью, если роль меняется быстрее документа. Вуз не подготовит человека к проекту, если вместо живых кейсов получает только гладкие презентации.

Общее в этих шести заметках — не тема бизнес-анализа в узком смысле. Общее — вопрос зрелости среды вокруг продукта.

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

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

Поэтому эти шесть заметок — про участок между «у нас есть решение» и «оно действительно изменило работу». Именно там обычно теряются сроки, деньги, смысл и взаимное доверие. И именно там у практиков больше всего материала для проверки, дополнения и спора.

Как и раньше, это не отчет и не стенограмма. Это попытка разложить услышанные на АКПО-Конф сигналы на понятные вопросы к практикам. Если узнаете свои проекты — пишите. Если видите контрпример — тем более пишите. Решение живет не от чьей-то уверенности, а от проверки на реальных внедрениях.

Рисунок, который визуально отражает главную идею статьи — столкновение быстрых ИТ-инструментов и зрелости бизнес-процессов. Изображние создано с помощью ИИ по тексту данной статьи.

Квалифицированный заказчик: инструмент сам себя не применит

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

В корпоративных ИТ есть удобная сказка: пришел новый инструмент, и работа ускорилась.

ИИ написал код. В low-code собрали форму. Прототип появился за день. Интерфейс выглядит прилично. Демонстрация прошла без пожара. Где-то в воздухе уже начинает шуршать отчет о повышении эффективности.

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

• Кто владелец данных?
• Что считается правильным результатом?
• Где граница автоматизации?
• Кто принимает решение при исключении?
• Какая ошибка допустима, а какая ведет к регуляторному, финансовому или производственному риску?
• Что меняется в роли человека после появления инструмента?

И тут выясняется неприятная вещь: инструмент может быть быстрым, а заказчик — не готовым.

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

Факты

По итогам АКПО-Конф

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

В дискуссии этот вопрос не свелся к привычному спору «заменит ИИ разработчика или не заменит». Обсуждение ушло в сторону ролей, ответственности и способности людей работать с новыми инструментами.

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

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

Но вдогонку прозвучал и обратный пример. Онлайн-перевод ценных бумаг между местами хранения и брокерами требует доработок в нескольких учетных системах, интеграциях и пользовательских интерфейсах. Там нельзя просто «накидать код» в восьми местах и считать, что проблема решена. Слишком много контуров, правил, данных и ответственности. Быстрый инструмент не отменяет опору на глубокую архитектуру процесса.

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

Что видно по российским реалиям

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

Но ожидание часто устроено слишком просто: если инструмент быстрый, результат тоже должен появиться быстро. Эта связка кажется естественной, пока не начинаешь разбирать задачу.

Быстро собрать экран — не то же самое, что изменить работу подразделения.

Быстро получить аналитическую выжимку — не то же самое, что принять управленческое решение.

Быстро сделать прототип — не то же самое, что встроить решение в безопасность, поддержку, данные, роли и регламенты.

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

Снаружи это выглядит как сопротивление пользователей. На деле это часто нехватка проектной квалификации у заказчика.

Что подсказывает наследие SAP

В SAP-проектах эта мысль знакома давно, пусть и под другими названиями. В подходе Fit-to-Standard заказчик не просто ждет, когда ему настроят систему. Эксперты бизнес-линий участвуют в разборе стандартных процессов, проверяют, как они ложатся на работу компании, помогают фиксировать требования и разрывы между стандартом и потребностями бизнеса.

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

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

Редакционно-логическое наблюдение

Квалифицированный заказчик — это не «клиент с бюджетом» и не «руководитель, который подписывает приемку». Это участник проекта, который умеет:

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

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

В первом случае компания получает быстрый прототип без внедрения. Во втором — автоматизацию вчерашней неразберихи.

Попытка объяснения

Проблема могла возникнуть из-за слишком соблазнительной картинки новых инструментов.

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

Все это правда. Но только наполовину.

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

Раньше эта сложность чаще пряталась внутри длинного ИТ-проекта. Теперь она выходит наружу раньше. И это полезно. Но только если заказчик готов с этим работать.

Иначе получается новый вариант старой проблемы: раньше заказчик приносил неясное требование и ждал, что аналитик с разработчиком его расшифруют. Теперь он может получить быстрый прототип и решить, что расшифровывать уже ничего не надо.

Надо. Просто теперь цена плохого понимания проявляется быстрее.

Гипотеза

ИИ, low-code и быстрые прототипы дают устойчивый эффект там, где заказчика заранее учат новой роли.

Не «нажмите сюда, чтобы получить отчет», а иначе:

• как описывать процесс;
• как формулировать задачу;
• как задавать критерии результата;
• как проверять качество данных;
• как отличать демонстрацию от рабочего решения;
• как понимать ограничения безопасности и поддержки;
• как принимать изменения в собственной работе.

Если такое обучение встроено в проект, инструмент ускоряет путь к результату. Если нет, компания получает быстрые картинки, медленную приемку и длинные споры о том, почему «почти готово» опять не дает результат.

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

Вопрос к читателям

Учите ли вы заказчика работать с новыми инструментами?

Не только пользоваться кнопками, а понимать процесс, данные, ограничения, критерии приемки и собственную новую роль. Есть ли у вас обучающие программы для внутренних заказчиков, владельцев процессов, ключевых пользователей, бизнес-экспертов? Что в них работает, а что превращается в обучение ради галочки?

Пишите на y.nechitaylov@sappro.ru, в сообществе в ВК или в комментариях под этими материалами на sappro.ru.

Ваши ответы помогут понять, где новый инструмент действительно усиливает заказчика, а где просто быстрее приносит ему непонятный результат.

Иногда требование начинается невинно: «сделайте кнопку фиолетовой». В проектах корпоративного ПО такая просьба редко бывает только про цвет. По итогам сессии «На пути к технологическому суверенитету: как бизнес-аналитики перестраивают российский ИТ-ландшафт» разбираем сигнал: хотелка становится требованием только после вопроса «зачем».

Все заметки главреда здесь.

Продолжение следует.

Автор

Юрий Нечитайлов, главный редактор SAP Professional Journal Россия