Неправильный подход к решению задачи есть и в сфере автоматизации предприятий. Достаточно большое количество первоначальных запросов на разработку CRM и ERP-систем (около 20%) приходит не с позиции решаемых задач, а с позиции наличия определенной суммы денег, которые заказчик готов потратить.
Вполне логично
С одной стороны, это логичный подход, но при наличии одного условия. Если руководитель компании нацелен на развитие и хочет в это инвестировать, имея определенную сумму денег на данное предприятие. В данном случае это действительно работает. Можно изучить бизнес-процессы, определить, автоматизация какой из областей работы поможет компании лучше всего, сделает её эффективней. Определить бутылочное горлышко, и внедрить автоматизацию именно в этом месте. В данном случае можно получить варианты помощи в автоматизации в рамках имеющегося бюджета. Однако, наличие данного фактора встречалось нам всего пару раз, остальными являются запросы другого характера.
Купить слона
Второй вариант — это наличие достаточно больших потребностей и очень маленький бюджет. Такие запросы рождаются вследствие недостаточной информированности о процессах и составе работ, необходимого для разработки системы автоматизации. Подробнее об этих процессах можно прочитать в статье про методологию разработки. Ценообразование в различных компаниях по разработке программного обеспечения отличается, однако всё сводится к тому, что компания делает для производства продукта и что будет получено в итоге.
Попытаться сэкономить — абсолютно правильное решение. Но при экономии надо понимать и разбираться в том, на чем именно происходит экономия. Необходимо выяснить, что входит в состав работ, за что платятся деньги. Очень осторожно следует относиться к согласию подрядчиком создать информационную систему за очень маленькую сумму.
Как правило, сэкономить возможно при подходе с готовыми системами и их перепродажей. Бывают и перегибы, когда заказчику просто перепродается готовая система, лицензия, с огромной наценкой. На практике мы сталкивались с ситуациями, когда разработка индивидуального решения оценивалась нами дешевле, чем неподходящий функционал купленной лицензии шаблонного продукта, который заказчик не знал куда деть и в итоге выкидывал. Это были деньги на ветер.
Если бюджет очень мал и потребности достаточно стандартны, мы рекомендуем посмотреть в сторону SaaS решений, которые хоть и не дают ровно то что нужно, но частично смогут помочь в автоматизации процессов.
Потерять всё
Несмотря на минимальный бюджет всегда найдутся те, кто согласится его освоить.
При разговоре с заказчиком, понимая, что работаем с подходом от бюджета, мы даем рекомендации, на что обратить внимание при выборе подрядчика. Рекомендуем использовать определенные приемы, чтобы минимизировать риск потери всего бюджета.
Итогом такого подхода в 90% случаев являются потерянные деньги. Это происходит по трем причинам: вечный перенос сроков, получение только части результата или результат, которым невозможно пользоваться.
При разработке индивидуального программного обеспечения самым распространенным вариантом реализации при желании сэкономить работает следующая логика. Пример — “нам нужна машина”. В ходе обсуждения выясняется, что нужно передвигаться, должно быть 4 колеса и место, на чем сидеть. Результат получается таким.
Что делать?
Если у вас есть определенный бюджет и необходимо решить определенную задачу по автоматизации блока работ, то чтобы не выкинуть деньги на ветер, необходимо тщательно отнестись к выбору подрядчика. Для этого необходимо определить, что вы получите за эти деньги детально. Недостаточно просто сказать “нам надо систему заказов, сделайте за 100 тысяч”, получить согласие и переводить деньги, надеясь на ожидаемый результат.
Для начала необходимо самостоятельно представить, что вам необходимо в итоге. Как правило, нет проблем с пониманием результата, именно бизнес-результата. Необходим учет заказов, контроль за ними. Но компании, которые выстроят всю цепочку получения данного результата от аналитики до внедрения, полностью избавляя от проникновения в проект, включают это в стоимость системы. Имея небольшой бюджет, необходимо самостоятельно понять, как это должно выглядеть. Это необходимо для того, чтобы соотнести то, что вам предлагают за указанную стоимость и то, что вы ожидаете. Чем меньше бюджет, тем более велик риск большого разрыва между ожиданиями и реальностью.
Чтобы не получить в итоге работ не только решение задачи не в том виде, в котором необходимо, но и вообще отсутствие решения бизнес-задачи, необходимо проникнуть в детали как минимум того, как это будет выглядеть. Понять, какие необходимы разделы и как вы видите их реализацию. Часто именно в этом месте происходит основной разрыв понимания проекта, что и приводит к разнице между ожиданиями, результатом и стоимостью.
Как это выглядит на практике. Вы говорите, что нужен раздел “заказы”. Вы сказали, что есть на это 100 тысяч и подрядчик сказал что да, он сделает заказы за эту сумму.
Вариант 1 (типичный). Вы заключаете договор, или договариваетесь на словах, начинается работа, вашему вниманию в виде результата предоставляется программа или WEB-сервис, в котором есть таблица “заказы”, а при нажатии на заказ есть окошко его редактирования, где есть стоимость. Далее вы говорите, что заказы надо комментировать, в заказах есть позиции заказов, старшие менеджеры должны видеть все заказы, а просто менеджеры только свои, и вообще где разделение на менеджеров? Но нанятый программист или подрядчик утверждает что вы хотели раздел заказы — вот он. А то, что вам нужно — это дополнительная стоимость. Вы считаете, что пользоваться этим бесполезно и невозможно. И начинается долгий процесс доработок за отдельные деньги, который затягивается на годы, пока подрядчик не пропадает.
Развитие системы и доработки — это нормальный процесс. Ключевой момент данного варианта — различие между вашими ожиданиями и результатом. Его причина — определение стоимости по недостаточным вводным данным и отсутствие синхронизации видения результата между вами и подрядчиком, и только после этого обсуждение стоимости.
Вариант 2. Вы понимаете что именно хотите и выразили это в структуре системы, в любом виде. Вы указали, что в системе должны быть роли менеджера, старшего менеджера и администратора, который будет эти роли назначать. Вы определили, что необходим раздел заказов и клиентов, потому что бывает по несколько заказов от одного клиента. Вы на листочке накидали, как примерно это должно выглядеть. Что должна быть возможность комментировать заказы, где будет панель с комментариями, что должна быть история заказа, изменения всех полей заказа для контроля. В заказе должны быть позиции. Также, так как бизнес-результатом должен быть контроль. Поэтому нужен раздел аналитики, в котором будут показываться заказы за период времени в виде графика и таблицы.
После того, как вы сложили всё это в единое целое, также стало понятно, что еще нужна роль для руководителя, которому будет доступна аналитика. Нужны справочники статуса заказов, по которому можно понимать на какой он стадии. Нужен раздел номенклатуры со стоимостью, чтобы каждый раз не списывать текстом новую позицию заказа и её стоимость.
После этого можно спрашивать подрядчика, сделает ли он это за 100 тысяч. Такой подход исключит 90% вероятности потери денег при заказе информационной системы.