Когда стройке не нужна заказная разработка: 6 признаков

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

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

Модель: подрядчик общестроительного профиля, 60 человек, три объекта в работе, около 55 накладных и 20 актов КС-2 в месяц, собственного производства нет, штатного ИТ-специалиста нет. Полная стоимость часа: прораб и мастер 900 ₽, инженер ПТО и сметчик 1 100 ₽, бухгалтер 844 ₽.

Что коробка делает штатно и почему это не обыграть

Отраслевые конфигурации на платформе 1С — «1С:Подрядчик строительства», решения на базе «1С:ERP Управление строительной организацией», сметный контур «1С:Смета 3» — закрывают из коробки то, на что заказная разработка потратит месяцы. Это не маркетинговое утверждение, а следствие объёма: в этих продуктах уже учтены унифицированные формы, отраслевые справочники и десятилетия чужих граблей.

• Унифицированные формы. КС-2, КС-3, М-29, М-15, акт на списание. Форма — это не таблица, а набор правил заполнения и контроля, и переписать их «под себя» стоит дороже, чем купить.
• Договоры подряда и субподряда с лимитами. Реестр, суммы, гарантийные удержания, привязка актов к договору. Всё это уже есть, и на этом обычно и заканчивается вопрос про заказную разработку у компаний до 100 человек.
• Сметный контур и связка с бухгалтерией. Нормативные базы, индексы пересчёта, выгрузка в учёт. Собственная сметная логика — самое дорогое, что можно заказать, и самое быстро устаревающее.
• Обновления под изменения законодательства. Формы и правила меняются, и в коробке это приходит с обновлением. В своей системе каждое такое изменение — оплаченная задача разработчику.

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

Шесть признаков, что разработка не нужна

1. 1Процессы типовые. Договор подряда, общестроительные работы, сдача по КС-2. Если ваш процесс можно описать словами из унифицированных форм, значит, под него уже есть продукт.
2. 2Поток меньше 60 накладных и 25 актов КС-2 в месяц. Ниже этого объёма ручная работа стоит меньше, чем автоматика, которая её снимает. Порог, на котором распознавание актов начинает окупаться одними часами, — около 190 актов в месяц, и это разобрано в материале про распознавание и сверку КС-2.
3. 3Нет собственного производства. Цех металлоконструкций, участок ЖБИ, столярка — вот что чаще всего не помещается в строительную коробку, потому что требует позаказного планирования. Если производства нет, самая частая причина заказывать разработку отпадает.
4. 4Один-два объекта одновременно. Сложность управления растёт не от числа людей, а от числа параллельных объектов: справочники, распределение накладных, техника, бригады. На одном-двух объектах любая коробка справляется без доработок.
5. 5Компания готова менять процесс под систему. Это самый недооценённый признак. Если руководитель говорит «сделаем как в системе, лишь бы работало», коробка подходит почти всегда. Если «система должна делать точно как мы привыкли» — начинается разработка, причём часто ради привычки, а не ради денег.
6. 6Нет штатного ИТ-специалиста. Своя система требует владельца кода: кто-то должен принимать доработки, вести среду, планировать обновления. Без такого человека собственная разработка через год превращается в зависимость от одного подрядчика — и это худший из возможных исходов.

Три признака, что разработка оправдана

Обратная сторона списка короче и жёстче. Достаточно одного совпадения, чтобы разговор о собственной системе перестал быть тратой денег, — но совпадение должно быть настоящим, а не «у нас всё немного по-другому».

1. 1
   Уникальный расчёт, которого нет ни в одном продукте

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

2. 2
   Постоянный обмен между тремя и более системами

   Учёт, сметный контур, система управления объектами, склад, кадры, портал заказчика. Когда систем три и больше, а обмен нужен не суточный, а оперативный, интеграционная логика становится самостоятельным продуктом. Тут и появляется прослойка — и вопрос уже не «коробка или разработка», а «сколько разработки поверх коробки».

3. 3
   Требования заказчика, которых нет ни в одном продукте

   Формат исполнительной документации крупного заказчика, его регламент информационной модели, отчётность по государственному контракту в собственной форме. Здесь разработка обосновывается не экономией, а допуском к контракту, и считать надо не окупаемость, а цену отказа от объекта.

Три сметы на одной компании

Ниже — три варианта для модельного подрядчика на 60 человек. Состав задач одинаковый: заявки с объекта, приёмка материалов, договоры и акты, себестоимость объекта, отчётность собственнику. Разница только в том, чем это реализовано.

Число 87 556 ₽ полезно держать при себе на переговорах. Оно переводит разговор из «своя система гибче» в проверяемую плоскость: покажите, какие именно операции она снимает и на какую сумму. У модельного подрядчика на 60 человек весь эффект от автоматизации снабжения и приёмки составляет порядка 140 000–160 000 ₽ в месяц — то есть разработка должна была бы забрать больше половины всего эффекта только на то, чтобы сравняться с коробкой. Полная методика этого эффекта — в материале про окупаемость автоматизации подрядчика.

Промежуточный вариант и где его потолок

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

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

Пять вопросов поставщику и один тест на своих данных

Всё, что написано выше, проверяется до подписания договора за один-два дня. Пять вопросов задаются письменно, ответы сохраняются — они пригодятся и через год.

1. 1Что происходит с нашими доработками при обновлении версии? Правильный ответ — «переносятся автоматически, потому что лежат снаружи» или «переносятся нами по регламенту, стоимость такая-то». Неправильный — «обычно проблем не бывает».
2. 2Какой обмен документирован и что именно отдаётся наружу? Нужен список объектов и полей, а не слово «есть API». Проверяется просьбой прислать описание обмена в виде документа.
3. 3Кто владелец справочника номенклатуры при обмене с бухгалтерией? Ответ «обе системы могут править» означает будущие конфликты. Хозяин должен быть один, и это решение принимается до внедрения.
4. 4Как считается лицензия при росте до 60 пользователей и сколько стоит рабочее место на пятом году? Здесь чаще всего прячется разница в стоимости владения, которой нет в коммерческом предложении.
5. 5Что входит в поддержку, каков срок реакции и что происходит с данными при расторжении? Формат выгрузки и сроки передачи должны быть в договоре, а не в переписке.

Когда заказывать разработку не надо, даже если бюджет утверждён

И честный конец. Есть три ситуации, в которых утверждённый бюджет на разработку — не повод её начинать, а повод пересчитать.

• Задача сформулирована как «чтобы всё было в одном окне». Единое окно — это отчётность поверх данных, а не новая система. Оно делается за 180 000–260 000 ₽ поверх того, что уже стоит, если данные сопоставимы. Если несопоставимы, новая система их не исправит.
• Причина — недовольство текущим подрядчиком, а не продуктом. Смена исполнителя стоит 30–50 % бюджета, смена системы — весь бюджет заново. Это разные решения, и путать их дорого.
• Компания растёт быстрее, чем идёт проект. Разработка на 7–9 месяцев проектируется под сегодняшнюю компанию. Если за это время число объектов удваивается, к сдаче вы получите систему под прошлый размер. Коробка в такой ситуации гибче именно потому, что её писали не под вас.
• Внутри нет человека, который будет владеть результатом. Собственная система без владельца через год становится чёрным ящиком, который умеет чинить один человек за пределами компании. Как это выглядит по шагам, разобрано в материале про ошибки автоматизации в строительстве.

Заказная разработка на стройке оправдана там, где у вас есть что-то своё. Если своего нет, вы платите 3 152 000 ₽ за то, чтобы получить чужое, но позже.