Кто создает проект и смету? Со стороны интегратора — команда предпроекта: аналитики и архитекторы. Они пишут ТЗ и каталог процессов, из которых рождается смета. Заказчик это согласовывает и утверждает бюджет.
Но вот в чем загвоздка. СНиПы и ГОСТы в строительстве работают потому, что там есть физика, типовые конструкции и предсказуемые материалы. В ERP мы имеем дело с бизнес-процессами и логикой, которые у каждого предприятия уникальны. Аналог СНиПов есть — это ГОСТ 34 и 19, а также стандарты самой 1С. Но они регламентируют оформление документов, а не трудоемкость. Именно поэтому в статье и предлагается подход, близкий к вашему опыту в НИИ: сначала проектно-техническая документация в виде каталога процессов и ТЗ, а уже потом смета. Это попытка вернуть ту самую прозрачность, когда заказчик понимает, за что он платит.
Насчет открытых смет. В госсекторе или НИИ это возможно, в коммерческом — увы. Заказчики и интеграторы связаны NDA и никогда не расскажут публично свою маржинальность и внутренние ставки. Открытые проекты на GitHub — это либо типовые решения, либо небольшие доработки. Полные сметы комплексных внедрений ERP в открытом доступе невозможны.
Спасибо, что поделились! Это как раз тот сценарий, который мы называем human-in-the-loop. ИИ не берет на себя ответственность за финальный ответ, но помогает найти и подготовить ссылки, а человек уже проверяет и принимает решение.
И отдельно здорово, что вы проверяете гипотезу на бесплатном DeepSeek. Это подтверждает подход из статьи: не тратить миллионы на пилот, а быстро и дешево понять, экономит ли инструмент время. Если да — можно масштабировать, если нет — вы ничего не потеряете.
Сокращение ФЗП — это самый простой способ посчитать эффект, но далеко не единственный и часто не самый весомый. Экономия может складываться из нескольких вещей. Например, ИИ увеличивает пропускную способность: если заявки обрабатываются быстрее, компания обслуживает больше клиентов теми же силами и зарабатывает больше. Или вспомните кейс со складом из статьи: там выгода не в том, чтобы сократить закупщиков, а в том, чтобы утилизировать остатки и не покупать новое. Это огромная экономия.
Ещё есть снижение стоимости ошибок. В юридических вопросах, где цена каждой ошибки высока, даже частичное снижение рисков дает ощутимый экономический эффект. Кроме того, на экономию влияет ускорение процессов: быстрее подготавливается смета, быстрее запускаются закупки, быстрее выводится продукт.
Согласны с вами - статья базовая и мы сами уровень сложности тьюториала обозначили как "простой", так как описываем готовые и знакомые инструменты. Но как их заставить работать вместе, чтобы ничего не ломалось, а ресурсы потреблялись правильно и рационально - задача нетривиальная, особенно для неискушенного инженера, вот мы и рассказали, как ее решать. А про cronjob что вы имели в виду - могли бы уточнить, как его можно для задач автомасштабирования применять?
Программа построена на основе 3 классических курсов RH (124, 134, 294), прохождение которых дают основополагающие качественные знания по работе с ОС Linux. Обучение проходит в синхронном формате с преподавателем и наставниками - экспертами компании.
Кроме того, важным элементом Linux Upscale является глубокое погружения в реальные задачи компании и закрепление знаний практическими навыками.
Интеграционная шина в составе одного из своих компонентов использует БД в качестве инструмента для хранения конфигураций интеграционных маршрутов и общих настроек. По умолчанию используется PostgreSQL. В рамках проверки совместимости подтверждена конфигурация, где PostgreSQL заменена на отечественную СУБД.
Спасибо за живой комментарий! Давайте по порядку.
Кто создает проект и смету? Со стороны интегратора — команда предпроекта: аналитики и архитекторы. Они пишут ТЗ и каталог процессов, из которых рождается смета. Заказчик это согласовывает и утверждает бюджет.
Но вот в чем загвоздка. СНиПы и ГОСТы в строительстве работают потому, что там есть физика, типовые конструкции и предсказуемые материалы. В ERP мы имеем дело с бизнес-процессами и логикой, которые у каждого предприятия уникальны. Аналог СНиПов есть — это ГОСТ 34 и 19, а также стандарты самой 1С. Но они регламентируют оформление документов, а не трудоемкость. Именно поэтому в статье и предлагается подход, близкий к вашему опыту в НИИ: сначала проектно-техническая документация в виде каталога процессов и ТЗ, а уже потом смета. Это попытка вернуть ту самую прозрачность, когда заказчик понимает, за что он платит.
Насчет открытых смет. В госсекторе или НИИ это возможно, в коммерческом — увы. Заказчики и интеграторы связаны NDA и никогда не расскажут публично свою маржинальность и внутренние ставки. Открытые проекты на GitHub — это либо типовые решения, либо небольшие доработки. Полные сметы комплексных внедрений ERP в открытом доступе невозможны.
Спасибо, что поделились! Это как раз тот сценарий, который мы называем human-in-the-loop. ИИ не берет на себя ответственность за финальный ответ, но помогает найти и подготовить ссылки, а человек уже проверяет и принимает решение.
И отдельно здорово, что вы проверяете гипотезу на бесплатном DeepSeek. Это подтверждает подход из статьи: не тратить миллионы на пилот, а быстро и дешево понять, экономит ли инструмент время. Если да — можно масштабировать, если нет — вы ничего не потеряете.
Сокращение ФЗП — это самый простой способ посчитать эффект, но далеко не единственный и часто не самый весомый. Экономия может складываться из нескольких вещей. Например, ИИ увеличивает пропускную способность: если заявки обрабатываются быстрее, компания обслуживает больше клиентов теми же силами и зарабатывает больше. Или вспомните кейс со складом из статьи: там выгода не в том, чтобы сократить закупщиков, а в том, чтобы утилизировать остатки и не покупать новое. Это огромная экономия.
Ещё есть снижение стоимости ошибок. В юридических вопросах, где цена каждой ошибки высока, даже частичное снижение рисков дает ощутимый экономический эффект. Кроме того, на экономию влияет ускорение процессов: быстрее подготавливается смета, быстрее запускаются закупки, быстрее выводится продукт.
Спасибо, поправили!
в одном материале сложно все охватить, как совет для будущих статей - супер, добавим критерии для сравнения
поправили, спасибо, что заметили!
Спасибо, что поделились! В нашем кейсе эта функциональность покрывается KEDA, но возможен и описанный вами вариант.
Согласны с вами - статья базовая и мы сами уровень сложности тьюториала обозначили как "простой", так как описываем готовые и знакомые инструменты. Но как их заставить работать вместе, чтобы ничего не ломалось, а ресурсы потреблялись правильно и рационально - задача нетривиальная, особенно для неискушенного инженера, вот мы и рассказали, как ее решать. А про cronjob что вы имели в виду - могли бы уточнить, как его можно для задач автомасштабирования применять?
Программа построена на основе 3 классических курсов RH (124, 134, 294), прохождение которых дают основополагающие качественные знания по работе с ОС Linux. Обучение проходит в синхронном формате с преподавателем и наставниками - экспертами компании.
Кроме того, важным элементом Linux Upscale является глубокое погружения в реальные задачи компании и закрепление знаний практическими навыками.
Интеграционная шина в составе одного из своих компонентов использует БД в качестве инструмента для хранения конфигураций интеграционных маршрутов и общих настроек. По умолчанию используется PostgreSQL. В рамках проверки совместимости подтверждена конфигурация, где PostgreSQL заменена на отечественную СУБД.
Спасибо! Исправляемся
Справедливо! Именно поэтому новости компании мы публикуем в ленте "Новости". А нашим опытом и историями реализованных проектов - в ленте "Статьи"
Кстати, о суперкомпьютере "Оракул" Алексей Зотов уже рассказывал в своей статье Штучная работа. Как мы собрали суперкомпьютер для моделирования новых материалов