В этой статье мы опишем 3 основных причины, по которым к нам обращаются за разработкой ERP и CRM-систем. Это можно назвать не причинами, а ситуациями, в которых оказались наши потенциальные клиенты.
1С-ERP
Самая распространенная ситуация. Компания когда-то внедрила 1С ERP и пришла к пониманию, что это не соответствует ожиданиям по качеству, скорости работы, гибкости, возможности доработок и растущей в процессе развития системы стоимости этих доработок.
Существует исследование в области продаж, подтверждающее эффект оправдания покупки. Его суть в том, что покупатель, приобретя товар, начинает искать оправдания для своего выбора и недостатки других товаров, которые не были приобретены. «Пусть эти кросовки неудобные, зато они имеют светоотражатели, что может помочь избежать наезда автомобиля в темное время суток». В отношении ERP-систем эффект такой-же, хоть и масштабы другие. Однажды мы услышали от одного из потенциальных клиентов: «Компания потратила 20 миллионов на то, что неработает, но если кто-то из руководителей это признает, то полетят головы, поэтому все будут молчать». Но проходят годы, развиваются бизнес-процессы компании, меняются технологии, и у руководителей некоторых компаний наступает точка кипения и осознание, что необходимо что-то менять.
Компании понимают, что автоматизация бизнеса нужна и важна, у них есть некоторый опыт оптимизации работы с помощью информационных систем, а также негативный опыт работы с вышеупомянутой системой, и они приходят к решению о необходимости разработки такой информационной системы, которая будет построена точно под бизнес-процессы компании и будет лишена недостатков, с которыми уже успели столкнуться.
Когда лицо, принимающее решение о разработке, только делает изначальный выбор, на какой платформе компании строить свою информационную инфраструктуру, ему стоит пообщаться с компаниями, уже работающими на этой платформе. Желательно длительное время.
Не всегда обращение в нашу компанию носит характер полной замены существующей системы. Часто это сначала разработка локальной информационной системы, автоматизирущей небольшой бизнес-процесс и интегрированной с 1С-ERP. Далее приходит правильное понимание, как развиваться в области автоматизации.
Некачественная работа подрядчиков
Второй наиболее распространенной причиной обращения к нам является отрицательный опыт работы с другими подрядчиками.
Пример 1. На протяжении 12 лет клиентом разработано 5 информационных систем, каждая делалась с нуля. Причины начинать всё заново различны, но основных было 2:
- Неадекватно растущая стоимость каждого последующего этапа доработки информационной системы. При этом совсем необязательно это может быть намеренное завышение цены или жадность подрядчиков. Как правило, причиной подобной ситуации бывает неправильная архитектура построения информационной системы, работа над ней несколькими подрядчиками или несоблюдение при разработке стандартов качества и наличие некачественного программного кода. Это относится в том числе к первой причине в данной статье. Каждая следующая итерация доработок вызывает всё больше проблем, а, соответственно, тратится всё болоьше времени на осуществление доработок. Наступает момент, когда дешевле сделать новую систему, чем дорабатывать предыдущую.
- Отсутствие понимания между подрядчиком и заказчиком. Это происходит при взаимодействии с отдельными специалистами (фрилансерами) или небольшими компаниями. При этом в процессе разработки отсутствует анализ, должный уровень проектирования и бизнес-процессы, отвечающие за ход разработки и взаимодействия между заказчиком и исполнителем, часто опыт у подрядчика недостаточен. Всё это приводит к разочарованию в конечном результате, потому что заказчик получает не то, что ожидал получить.
Пример 2. Компания уже обращалась к нам ранее, 2 года назад, однако тогда даже предварительная стоимость разработки показалась им завышенной. Мы дали рекомендации, на что обратить внимание при заказе разработки, и на этом расстались. Компания обратилась к фрилансерам и разработала систему, однако внедрить её так и не удалось. Несмотря на то, что в ходе большого количества итераций удалось получить требуемый функционал, сама система была написана на стеке технологий, который уже около 10 лет утратил свою актальность. Кроме того, скорость работы системы оказалась неудовлетворительной (загрузка одной страницы с данными более 30 секунд). Клиент в конечном итоге от нас получил необходимую систему, такую, какой она должна быть, но 2 года и потраченные деньги уже не вернуть.
Пример 3. Похож на пример 2. Компания обращалась за год до заказа сайта. Мы сообщили предварительную стоимость, она компанию не устроила. Через год компания вернулась со словами «мы поняли, потратили миллион рублей, сделав 3 попытки, давайте теперь делать нормально».
Последние 2 примера связаны с желанием сэкономить, и это правильное желание. Однако стоимость разработки должна быть не дорогой и не дешевой, а объективной. Для определения стоимости существует 2 разных подхода:
- Назвать стоимость на основании перечисленных требуемых разделов, послюнявив палец и определив направление ветра, посмотрев на клиента и предположив, сколько он может заплатить.
- Составить детальную смету на разработку, предварительно определив состав информационной системы, детализировав требования, составив прототипы и техническое задание.
Если вы надеетесь получить качественный результат (или получить его вообще), то важно понимать, что разработка информационной системы – это командная работа, в которой в течение нескольких месяцев задействованы аналитик, менеджер проекта, дизайнер и программисты. Чтобы примерно понять стоимость, достаточно сложить зарплаты данных специалистов.
Помощь внутреннему IT-отделу
Это тоже распространенная причина. Компании, вставшие на путь автоматизации бизнес-процессов, иногда уже имеют внутренний IT отдел или даже департамент. Его задача, как правило, поддерживать существующую IT-инфраструктуру, иногда дорабатывать основную информационную систему компании. Однако возникает ситуация, при которой необходимо автоматизировать работу отдела или бизнес-процесс, который еще не автоматизирован.
В этом случае можно создать информационную систему, которая будет выполнять указанные функции и будет обмениваться данными с основной информационной системой. Такого рода информационные системы называются инкапсулированными. Основная информационная система, которую обслуживает IT-отдел, не знает и не должна знать, как работает локальная информационная система.
Такая концепция обусловлена структурой бизнес-процессов компании и применима для любой компании.
Например, промышленное предприятие. Существует бизнес-процесс изготовления изделия, от заготовок и материалов до отгрузки продукции. Однако существует бизнес-процесс оценки качества продукции и осуществелния проверок качества в ходе производственного процесса. В данном случае информация об изделиях и стадии процесса передается в локальную информационную систему, в которой работают инженеры по качеству. Для инженеров по качеству в системы выстраивается очередь задач, на каком месте производства, в каком заказе и какие изделия проверить, также показывается, что именно необходимо замерить, какие показатели вписать, сделать фотографии. Далее в основную информационную систему передается информация о наличии брака или об успешном прохождении проверки, после чего уже основная система действует по своему бизнес-процессу.
При обращении за разработкой локальной информационной системы предприятию нет необхродимости расширять IT-отдел, строить систему разработки и проектирования. Достаточно заказать информационную систему, и далее принять её в эксплуатацию силами внутреннего IT-отдела. Финансово и организационно выгодное для предприятия решение.