«Сколько стоит час работ?» – возможно, вы начинаете сравнение подрядчиков 1С не с того вопроса

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

При таких вводных ставка часа может стать одним из самых понятных и одновременно самых обманчивых критериев для выбора подрядчика на проект автоматизации. Ведь она создаёт ощущение, что экономика уже может быть посчитана.

Вот две ставки: одна из них заманчиво ниже – значит, этот подрядчик дешевле. На бумаге арифметика выглядит убедительно.

Но в проекте автоматизации – так просто всё почти никогда не работает.

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

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

Ставка – лишь один множитель. Второй – количество часов, которое потребуется для достижения результата. И команда со ставкой выше может в итоге обойтись дешевле, если она не будет учиться за счёт заказчика, создавать лишние доработки и раздувать проект.

Высокая ставка сама по себе ничего не гарантирует. Но и низкая ставка ещё не делает проект экономным. Она говорит лишь о том, сколько стоит час. Всё остальное зависит от качества решений подрядчика.

А как же оценка в коммерческом предложении?

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

Этот диапазон не нейтрален. Одна команда будет искать, как удержаться ближе к его нижней границе. Другая последовательно выберет более трудоёмкие варианты, доберётся до верхней границы, а затем обнаружит работы, которые якобы невозможно было предусмотреть заранее.

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

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

Основная экономия начинается до разработки

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

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

Формально работа выполнена безупречно. Но бизнес мог получить дорогой набор функций вместо решения исходной проблемы.

Зрелый подрядчик отличается от передаточного звена между пользователем и разработчиком тем, что не начинает с вопроса «что нужно доработать?». Сначала он выясняет, зачем это нужно, какую цель преследует компания и что должно измениться после запуска. Только после этого можно решать, требуется ли разработка вообще.

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

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

Бизнес не должен подстраиваться под типовую 1С любой ценой

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

Типовая система – инструмент, а не цель проекта. Если бизнес-процесс сейчас выглядит определённым образом только потому что он таким «исторически сложился», содержит лишние согласования и не создаёт никакой ценности, его действительно разумно пересмотреть. Особенно когда новый процесс одновременно становится проще для бизнеса и лучше поддерживается в 1С.

Возможна также ситуация, когда для бизнеса оба варианта (существующий и предлагаемый подрядчиком) практически равнозначны, но один потребует серьёзной доработки, а второй реализуется настройками. Тогда выбор менее трудоёмкого варианта вполне оправдан.

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

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

Самая дорогая доработка – та, что уже существует в типовой 1С

Знание типового функционала напрямую влияет на бюджет проекта. В «тяжелых» конфигурациях 1С одна и та же бизнес-задача может решаться несколькими штатными механизмами, причём нужная возможность не всегда лежит на поверхности. Если команда знает систему недостаточно хорошо, пробел в её компетенциях превращается в техническое задание на разработку.

Заказчик в этом случае платит дважды. Сначала – за создание того, что можно было настроить. В будущем – уже при поддержке системы – за тестирование, обновление и сопровождение нетипового решения. Чем больше таких доработок накапливается, тем дороже обходятся последующие изменения.

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

Опыт прошлых проектов должен приносить пользу, а не украшать портфолио

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

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

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

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

Но адаптация и частичная доработка подходящего решения, в сравнении с его проектированием и разработкой с нуля – это два совершенно разных объёма работ. Даже с учётом проверки применимости разница остаётся существенной. Заказчик экономит не потому, что получает чужое решение, а потому, что подрядчик не начинает каждый проект так, будто до него ничего подобного не существовало.

В эпоху ИИ ведущие эксперты должны принимать решения, не занимаясь рутиной

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

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

Принцип здесь простой: рутину должна забирать автоматизация, решения должны оставаться у сильных специалистов.

При этом рост производительности подрядчика должен отражаться и на экономике проекта для заказчика. Если команда выполняет механическую часть задачи быстрее, странно продолжать оценивать её так, будто трудозатраты не изменились. ИИ не должен становиться только источником дополнительной маржи интегратора. Часть полученного выигрыша должна проявляться в оценке, сроках или объёме результата, который заказчик получает за те же деньги.

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

По каким признакам определить подход подрядчика ещё до заключения договора

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

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

Есть несколько признаков, которые можно увидеть ещё до договора:

• подрядчик спрашивает не только о функциях системы, но и о целях бизнеса;
• предлагает несколько вариантов решения и объясняет различия между ними;
• не объявляет единственно возможный путь до изучения процессов и данных;
• хочет разговаривать не с одним представителем, а с расширенной рабочей группой заказчика – со всеми заинтересованными;
• заранее обсуждает риски, зависимости и участие команды заказчика;
• показывает релевантный опыт компании или специалистов, которые действительно будут работать на проекте;
• знакомит заказчика с руководителем проекта, функциональным архитектором или другими экспертами, от которых будут зависеть ключевые решения.

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

Высокая ставка не является автоматической гарантией

Из всего сказанного не следует, что нужно выбирать подрядчика с самой высокой ставкой. Дорогая команда может работать медленно, предлагать избыточные решения и допускать ошибки. Цена часа не подтверждает квалификацию. Также, как низкая цена не доказывает экономность.

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

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

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

Дешёвый проект, который не решил бизнес-задачу, стоит 100% потраченного бюджета

До сих пор речь шла преимущественно о стоимости работ. Но экономика проекта шире сметы.

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

Если проект обошёлся дешевле ожидаемого, но сотрудники продолжают выполнять ту же рутину, ошибки остались, расходы не сократились, а сервис не изменился – инвестиция не окупится. И неважно, что формально на проекте получилось сэкономить. Ведь фактически бюджет потрачен впустую.

Это не означает, что за бизнес-результат отвечает только подрядчик. Команда заказчика должна участвовать в интервью, принимать решения, согласовывать модель, готовить данные, менять привычный порядок работы. Система не трансформирует бизнес без участия самого бизнеса.

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

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

Ставка отвечает на вопрос, сколько стоит один час. Экономика проекта начинается с другого вопроса: какие трудозатраты понадобятся, какие решения будут приняты за это время и приведут ли они к результату, ради которого компания вообще начала проект.

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