Обновить

А кто в IT отрасли отвечает за одобрение решений типа ERP или Управление предприятием, холдингом?

Почему по умолчанию считается, что любой выпущенный любым вендором продукт из вышеуказанной линейки - это БИЗНЕС-ПОЛЕЗНЫЙ продукт, которым можно безопасно для бизнеса предприятия или холдинга пользоваться?

"Одобрено и куплено клиентом" - так себе критерий БИЗНЕС-ПОЛЕЗНОСТИ?

Например, никто в строительной отрасли или в медицине, не сможет запустить "проект" только по желанию клиента. Строить дом, который не выдержит нагрузок и "сложится" без соответствия сопромату и строительным нормативам/технологиям, или сделать операцию, по желанию клиента, без одобрения врача и соответствия медицинским рекомендациям/технологиям НЕЛЬЗЯ, какие бы бумаги не подписал клиент и как бы он не просил сделать так, как ему хочется! И это знают и принимают обе стороны (Клиент и Поставщик услуг)! И поэтому очень строгие допуски в строительную и медицинскую отрасли!

Почему в IT отрасли так МОЖНО!? Почему соответствие IT требованиям (безопасность данных, отсутствие багов и т.п.) - это достаточное условие для одобрения БИЗНЕС-ПОЛЕЗНОСТИ IT продукта! А как же соответствие прикладным БИЗНЕС регламентам/технологиям?

Кто сказал, что, например, 1С:ERP - это БИЗНЕС ПОЛЕЗНЫЙ продукт! Кто те эксперты и на соответствие каким прикладным бизнес-стандартам/технологиям они проверили соответствие и с какими результатами одобрили проверяемый продукт? Где это можно посмотреть? Хоть кто-то его возможности в прикладных аспектах проверял?

Почему результатов "автоматизация хаоса" недопустимо много и за это никто в IT отрасли не несет ответственности!? По аналогии: дом рухнул, клиент в результате операции заболел еще сильнее/умер - виноват сам клиент!? Не застройщик, не врач!? Этого не возможно представить!? А в IT отрасли - это НОРМА! Почему в IT отрасли считается, что в негативных результатах автоматизации хаоса однозначно виноват клиент, а не продукт IT вендора, который оказывается В ПРИНИПЕ не способен был решить тех проблем клиента, которые обещал решить? Чего только вендоры не обещают рекламируя свой продукт в стиле "наш продукт умеет все и решит все проблемы предприятия"! Но кто проверяет, правдивость этих утверждений? Кто проверяет, способен ли в ПРИНЦИПЕ продукт решить такие-то проблемы предприятий? Кто наказывает вендора за некорректную рекламу (за заведомую ложь)?

Мне кажется, на эту тему стоит задуматься?

PS Может существует какая-то процедура валидации (опытное внедрение в рамках разработки) перед выпуском продукта на рынок?

Теги:
Рейтинг0
Комментарии14

Путь к ИИ‑сингулярности

У нас было два репозитория неоттестированного вайб‑кода, семьдесят пять тяжеловесных SDD‑спецификаций, пять обмазанных смазкой харнессов, солонка, наполовину полная кастомных скиллов и забитых капслоком правил, с десяток дырявых MCP‑серверов, RAG‑база со свежевекторизованным Confluence, самодельная дощечка имаго‑кодинга и целая россыпь автономных агентов всех мастей, от безобидных автодополнялок до галлюцинирующих субагентов, ставящих пакеты со slopsquatting и втихаря сносящих боевые базы.

Не то чтобы все это было действительно нужно для поездки к ИИ‑сингулярности, но если уж начали участвовать в спуске с горы на велосипеде без седла, остановиться уже невозможно.

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

Нет ничего более беспомощного, безответственного и испорченного, чем IT‑команда, запустившая мультиагентный оркестр в режиме allow all.

Это критический (и слегка ехидный) обзор того, что произошло с разработкой последние пару лет.

Путь к ИИ‑сингулярности

Публикации