Как определить на ранней стадии работы с компанией, во сколько будет обходиться поддержка продукта и его доработка? Затраты могут быть совершенно различными, на это влияет тип проекта и тип его развития и эволюции. Например, ERP-система может быть разработана и потребуется один этап доработок того, что не учли при проектировании. А может развиваться по принципу создания MVP или локальной автоматизации по отдельному бизнес-процессу или проблеме, а потом будет поэтапно развиваться, требуя постоянных доработок.
Оценка стоимости большого этапа работ по модернизации ERP и оценка минимальных доработок и обращений по мелочам имеют как разные, так и общие принципы.
Оценка стоимости большой системы
Во всех компаниях, занимающихся разработкой ERP-систем есть принципы ценообразования. В тех компаниях, где продается шаблонный продукт, на него имеется наценка, часть из которой платит компании по партнерской программе производитель. В остальном — оценивается рабочее время, необходимое для работ по настройке или созданию дополнительных модулей. В компаниях, где разработка производится “под задачи клиента” — стоимость складывается только из работ. У каждой компании свои факторы оценки, но общим является подход оценки трудозатрат по необходимому времени и типам работ. В отличие от разовых обращений и небольших доработок в рамках работ по поддержке ERP-системы при проектной работе, достаточно большое количество ресурсов тратится на проектирование. На этом же этапе закладываются риски непредусмотренных работ, на доводку системы. В то же время стоимость уменьшается за счет комплексности работ и снижения издержек на организационные процессы.
При подборе исполнителя заказчик ориентируется на свое понимание оценки стоимости. Крупным заказчикам близок сметный подход и они более ориентированы на оценку по часам. Менее крупным заказчикам подходит работа за результат. Также есть и альтернативный подход. Мы описали для вас особенности каждого подхода, так как практиковали и используем для клиентов более удобный для каждого вариант.
Поддержка ERP-системы с почасовой оплатой
Данный подход наиболее приближен ко внутренней оценке компаний только на первый взгляд и имеет несколько подводных камней.
Одна сторона монеты
При таком подходе заказчик так или иначе ориентируется на стоимость часа работы сотрудников в компании, попадая тем самым в ловушку. Потому что одну и ту же задачу в одной компании сделают за 1 час, в другой — за 2, а в третьей выставят счет за 20 часов. При этом важно понимать, что действительно одну задачу можно выполнить качественно, так, как надо, и заложить возможность последующих изменений (особенности программирования), потратив на это 10 часов, а можно сделать за 5, но “как в последний раз” и “после меня хоть трава не расти”. Во втором случае выполнение последующих задач будет постоянно увеличивать трудозатраты на их выполнение.
Манипуляции и оценка
Что должно оцениваться? Работа программиста имеет свои особенности. Это не просто голое время написания кода. И опять же, в зависимости от степени профессионализма, любая задача выполняется разное время. Задачу необходимо проанализировать, выбрать оптимальный вариант решения и только потом написать код именно там, где это надо и столько, сколько надо. Практически всегда в компаниях разработчиков есть объективная оценка (у разных компаниях разная), сколько времени необходимо программисту для решения определенной задачи.
Однако, рано или поздно на стороне заказчика появляется представитель, который начинает говорить, что “тут кода немного, и поэтому его написать можно быстрее”. И он прав, переписать готовый код с секундомером действительно выйдет быстрее, а если перед этим еще пройти тренировку на клавиатурном тренажере и печатать по 400 символов в минуту, то данная задача должна занимать не несколько часов а несколько минут. И на эту тему могут возникать разногласия между заказчиком и исполнителем.
Экономика
Почасовая оценка выполняется с затратами минимум 1 час на каждый функциональный элемент и действие. Если задача оценена и выполняется несколько часов, то это менее заметно, но если это множество мелких задач или отдельная небольшая задача, то стоимость для заказчика увеличивается. Это происходит потому, что в комплексе выполнять и оценивать задачи выходит по времени меньше, чем если делать их по одной. Ведь есть задачи, которые выполняются и за 15 минут и даже за 5. При почасовой оценке они обойдутся заказчику дороже. При этом оценка на задачу минимум в 1 час, даже самую мелкую, оправдан, ведь процесс выглядит так. Надо поставить задачу разработчикам, им необходимо с ней ознакомиться , развернуть проект, найти место, куда нужно внести изменения, произвести необходимые изменения, собрать проект и отправить данные на сервер. В случае работы с логикой и программной частью необходимо еще и проанализировать задачу, найти оптимальный вариант решения, убедиться, что изменения не затронут другие части системы, а после выгрузки протестировать. Даже если изменения незначительные.
Простота оценки
Проектирование и разработку ERP-системы нельзя сравнивать с заменой колеса на автомобиле. В данном случае мы говорим не о том, что одно сложнее другого или первое лучше второго. А о том, что замену колеса гораздо проще определить по затратам времени. В отличие от программирования не надо большую часть времени вместо фактического закручивания гайки думать: закрутить по часовой или против часовой. Эти операции имеют набор предопределенных действий, которые можно оценить с секундомером и оценивать по прайсу времени.
Кстати, с закручиванием гаек на колесе тоже можно провести аналогию. Можно попробовать их забить, а не закручивать. Это будет быстрее. Колесо потом конечно отвалится, а следующий мастер скажет, что надо менять весь блок деталей, но ведь это будет потом. Зато на выполнение задачи будет потрачено меньше времени. Если с колесом для заказчика это очевидно, то с программным кодом — нет.
В программировании есть задачи, которые можно классифицировать и оценивать, об этом следующий раздел.
Практика
У нас был клиент, который оплачивал услуги по поддержке сайта в таком формате: договор был на 20 часов в месяц. Клиент ушел к другим исполнителям из-за стоимости часа. Другие исполнители в течение трех месяцев, потратив 60 часов по договору, внедряли определенный элемент интерфейса на сайт. Они так и не закончили работы. После этого заказчик вернулся к нам. Работы по внедрению этого же элемента интерфейса заняли у нас 2 часа.
Вывод
Данный подход менее экономичен, чем третий подход, но более выгоден, чем второй. При отсутствии собственного отдела тестирования возможны манипуляции со стороны исполнителя. Подходит для работы с фрилансерами при наличии должного контроля. При работе между компаниями больше подходит третий подход. При ориентировании на стоимость часа приводит к управленческим ошибкам со стороны заказчика.
Поддержка ERP-системы с предварительной классификацией задач
Данный подход основан на предварительной оценке стоимости типовых операций для понимания состава работ клиентом. Конечно, данный подход не позволяет оценить индивидуальные вещи, например, создание кастомного компонента интерфейса, формирование и вывод отчета или создание программных классов для вычислений, необходимых для работы системы. Данные вещи оцениваются отдельно в рамках третьего или первого подходов. В прайсе типовых задач подобное классифицируется как отдельная оценка исходя из задачи.
Экономия для клиента
А точнее, её отсутствие при таком подходе. Данный подход с точки зрения экономии для заказчика хуже первого и третьего подходов. Приведем пример. Пункт прайса может выглядеть как “Изменение внешнего вида элемента интерфейса, не связанное с изменением данных и обменом данными с сервером”. И имеет свою статичную стоимость. В эту стоимость разработчик закладывает максимальные работы, которые могут быть связаны с этим пунктом.
Например, есть задача изменить кнопку. Следовательно, с одной стороны для заказчика появляется некий вариант прозрачности, с другой, каждый раз, когда необходимо чуть-чуть изменить цвет кнопки, он заплатит за её перемещение, перекраску, изменение шрифта и размера. То есть за весь объем работ, который возможно будет реализован в данном пункте.
Практика
Данный подход применяется организациями с необходимостью заключать типизированный договор с приложением стоимости тогда, когда формат работы организации с подрядчиками регламентирует такой подход. Также данный подход оправдан и позволяет избегать конфликтов при оценке стоимости между заказчиками и разработчиками, если на проекте выполняется множество типовых операций. В рамках индивидуального подхода для конкретного проекта и заказчика может быть выработан подобный индивидуальный прайс.
Вывод
Данный подход применим при большом количестве однотипных задач на проекте. Подходит для поддержки сайтов, где работами являются выкладывание статей, добавление администрируемых панелей в разделах, замена контента. Для ERP и CRM-систем данный подход менее применим, потому что большинство задач необходимо оценивать индивидуально по первому или третьему подходу. При решении индивидуальных задач в поддержке ERP-систем, дробление больших задач на задачи по прайсу является самым неэкономичным подходом для заказчика.
Поддержка ERP-системы с оценкой результата
Имея опыт работы со всеми тремя подходами, можем сказать, что данный подход является самым экономичным и наиболее эффективным для заказчика. Суть такого подхода — микроэтапы разработки, включающие пул задач по доработке ERP-системы.
Этапы и отдельные задачи
Данный подход позволяет отталкиваться не только от стоимости часа разработки отдельной задачи, но и группировать задачи, а также объективно оценивать их административное обеспечение выполнения. Если выполняется отдельная маленькая часовая задача, то данный подход фактически не будет отличаться от почасовой оценки, и даже на пятиминутную задачу уйдет время, описанное в первом подходе (разворачивание проекта, определение места, тестирование, выгрузка).
Однако, если задач несколько, например 3, то при почасовой оплате это будет 3 часа, при оплате за результат — 2. Потому что задачи будут сгруппированы в стэк, оценены по фактически необходимому общему времени.
Результат и его стоимость
Прошлые два подхода — оценка процесса, данный подход — оценка результата. То есть, для заказчика стоимость формируется исходя из желаемого результата, к которому он предъявляет определенный набор требований. Он видит итоговую стоимость и может сравнивать её с ценами конкурентов, конечно, не забывая о факторе качества. Данный подход, если исключить факторы качества и множество других факторов, которые необходимо учитывать при выборе подрядчика, в отличие от первых двух подходов не имеет дополнительных факторов для манипуляций и мнимой прозрачности. То есть имеется результат и его стоимость.
Данный подход позволяет заказчику легко определить, стоят эти доработки и ожидаемый результат предлагаемых затрат или нет.
Вывод
Данный подход является самым эффективным и экономичным, содержит меньше подводных камней, чем другие подходы. Он применим при проектном развитии ERP и CRM-систем, хорошо применим при группировании задач в этапы доработок. Для максимальной эффективности результат необходимо описывать детально. У заказчика и исполнителя не должно быть разного понимания результата. Неопределенность результата сводит на нет все плюсы подхода, тогда и заказчику и исполнителю лучше работать в формате оплаты за процесс (почасовой подход). Данный подход оправдан при работе с компанией исполнителем, когда есть гарантия или уверенность что всё будет сделано качественно.
Общий вывод
Небольшие компании (до 100 человек) обычно ориентированы на работу по третьему подходу, и это логично. При работе с крупными компаниями со стороны заказчиков мы часто сталкиваемся с желанием работать по первому варианту.
Первый и второй подходы — это история больше про процесс, необходимую регламентированную бюрократию или иллюзию контроля, третий подход — про результат. Основываясь на опыте работы во всех трех форматах, мы предпочитаем работу по третьему варианту, но можем работать и по двум другим. Заказчику необходимо понимать разницу в данных подходах. Если понимать разницу и подводные камни, то применимы все подходы в той или иной форме.