Доброго вам понедельника, коллеги.

В профессиональных публикациях и обсуждениях я все чаще стал встречать любопытную (мне) подмену: человек осваивает конкретный программный продукт и на этом основании начинает считать себя специалистом по предметной области, для которой создан этот продукт. Это очень заметно в бизнес-анализе. Достаточно пройти курсы по тому же Битрикс24, научиться настраивать "бизнес-процессы", освоить маршруты согласования, роли и статусы, чтобы объявить себя бизнес-аналитиком.

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

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

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

И нет, речь не о том, что специалисты по Битрикс24, ERP, CRM или low-code "ненастоящие". Это нормальные специализации. Проблема возникает в претензии на универсальность: когда умение работать в продукте объявляется достаточным основанием для экспертизы в анализе деятельности. И дело не только в названии профиля. Такой специалист приходит к заказчику и предлагает решения, исходя прежде всего из того, что умеет реализовывать. Постановка проблемы подстраивается под имеющийся ответ.

И это не умозрительная опасность, совсем нет. В исследовании Raduescu и соавторов, посвященном крупным проектам процессного моделирования, участники сообщали о случаях, когда ограничения инструментов определяли содержание моделей вместо особенностей реальной деятельности. Другие исследования внедрения ERP показывали, как организации адаптировали собственные практики к логике программных систем. Адаптация не всегда вредна, но это означает, что сама возможность такой подмены вполне реальна.

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

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

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

P.S. Как всегда, много и нудно на эту тему можно почитать на GBAK.