Такие проверки не для повышения уровня бюрократии, а для системной сверки изнутри и снаружи. Однократная проверка или сбой не говорит, что вся система сломалась. Но позволит обратить внимание на ситуацию.
Чинили тюнингом в карточке сделки и внесли дополнения в регламент. Повторную проверку провели примерно через квартал. Это оптимальный срок, чтоб понять, что новые правила "прижились".
Спасибо, ценный комментарий.
Цена ошибки действительно определяет, куда ИИ заходит в первую очередь. Внутренние сценарии (классификация, маршрутизация) безопасны, т.к. там ошибку гасит оператор, и клиент её не видит. Как только ИИ выходит на прямую коммуникацию, метрики смещаются со скорости на точность и доверие. Ваш подход с честным «вы говорите с роботом» — правильная страхующая мера.
Но именно поэтому в нашем исследовании мы и видим такую картину: только 18% компаний используют ИИ в промышленной эксплуатации, а 64% пока вообще его не применяют в ITSM. Бизнес интуитивно чувствует этот порог — он не торопится запускать внешние сценарии, пока не убедится в качестве данных и не нащупает границы ответственности. И ваш комментарий как раз объясняет, почему компании топчутся на классификации и не идут дальше — цена ошибки держит.
С выделенным критерием «берите готовое и не мучайтесь» абсолютно согласен. Но в нашем случае речь не просто о коробке с набором преднастроенных сценариев, а о внедрении low-code-платформы. Вещи разные, хотя путают их не реже, чем прототип с продуктом. Фундамент действительно получаете сразу: модель данных, роли и права, интеграционные механизмы, аудит, ФСТЭК-контур. А вот свой процесс все равно придется собирать – только преимущественно конфигурацией, а не кодом.
При этом сложность внедрения зависит не столько от самого подхода, сколько от возможностей конкретной платформы. Рамки у всех low-code разные: то, что на одной платформе уже считается нетиповым процессом и требует обходных решений, на другой закрывается штатными средствами. Поэтому я бы смотрел не только на то, сколько процессов укладывается в стандартные сценарии, но и на то, насколько широк сам набор этих сценариев и платформенных возможностей.
По той же причине не соглашусь, что AI-driven просто наследует ограничения обоих подходов. Он скорее меняет знаменатель. Вопрос не только в том, что ИИ умеет собирать сценарии, а в том, к какому объему платформенных примитивов он имеет доступ. У BPMSoft, например, через отраслевые скиллы агенту доступно около 400 low-code операций. То есть он работает с проверенными операциями платформы, а не генерирует произвольный код поверх нее.
Каждая такая операция расширяет класс задач, которые можно решить внутри поддерживаемого контура платформы. Поэтому граница, за которой начинается кастомная разработка и связанные с ней вопросы поддержки, отодвигается дальше. Потолок, конечно, остается – как и у любой платформы. Просто он становится заметно выше.
0 не дописали?
Да, используем как калибровку и по одной проверке никаких резких движений не делаем. Стараемся повторять время от времени и смотреть комплексно, вместе с внутренней оценкой процесса.