Как на самом деле
Мы могли бы сейчас рассказать о том, что особенно о безопасности стоит заботиться разработчикам, ритейлерам, клиникам и т.д. Но нет — заботиться о безопасности клиентской базы и данных нужно всем. Нет ничего серьёзнее, чем информационная безопасность компании и в частности клиентской базы. Даже если вы крошечное агентство наружной рекламы или партнёр Директа, ваши данные будут как раз кстати конкурентам. Которые, вопреки вашим ожиданиям, не дремлют, а активно охотятся за вашими менеджерами с базой. А ещё есть обиженные сотрудники, мошенники, недобросовестные провайдеры без соблюдения SLA — и всё это кумулятивный риск для вас, вашего бизнеса, ваших денег. Мы рассказываем вам всё на примере CRM-системы как наиболее универсально ПО, которое должно быть вообще в любой компании, но на самом деле угрозы безопасности есть в любом софте: можно точно так же повредить или украсть чертежи, код, аналитику, фото, схемы, логику бизнес-процессов, финансовые документы, списки поставщиков и многое другое. Даже в военных ведомствах, где вроде бы все устроено серьёзно с точки зрения безопасности, случаются инциденты типа передачи секретных данных третьим лицам.
Культиватор без ТЗ, как работает — ХЗ
Никогда не пишите ТЗ и не собирайте требования
Вы знаете, что вендор составляет техническое задание за дополнительную плату? Ни в коем случае не давайте ему заработать! Хороший вендор, как правило, внедрил программное обеспечение не одной сотне компаний, а значит должен быть опытным и навскидку знать, какая автоматизация нужна любому бизнесу. Профессиональный вендор — практически провидец, он знаком с любым типом бизнеса и способен решать проблемы любой компании на лету. Конечно, вашему поставщику CRM, ERP, PLM и т.д. может сильно повезти, если у вас осталось ТЗ на программное обеспечение, оставленное предыдущим разработчиком лет 5 назад. Отдайте это техническое задание вендору, он будет счастлив. Если вендор почему-то создал ТЗ и отдал вам его на подписание — ничего не читайте и не вникайте в суть документа, это же не договор, а просто бумажка для успокоения нервов инженеров вендора. Отказавшись от составления ТЗ, вы не просто сэкономите деньги — вы спасёте себя от контроля за каждым этапом внедрения — вы платите настоящим профи, зачем что-то ещё контролировать. Они обязаны вам предоставить софт, который будет четко соответствовать вашему глобальному требованию «Я подразумевал, что это должно было быть именно так». Ну и конечно, ни в коем случае не собирайте требования со своих коллег. Вот представьте: нужно сформировать рабочую группу, пересмотреть процессы, опросить сотрудников, проанализировать информацию, выделить требования… И это в рабочее время! Ну сами посудите — что особенного может быть в продажах или производстве?
Как на самом деле
В жизни техническое задание лежит в основе успешного внедрения. Это документ, который создаёт разработчик, причём как правило делает это за отдельную плату, ведь для подготовки ТЗ требуется провести анализ требований клиента, погрузиться в его задачи, выбрать модель разработки, спроектировать и максимально детально описать работу создаваемых механизмов и функций, изложить все это в печатной форме и согласовать с заказчиком. Техническое задание подписывается наряду с договором, но в отличие от типового договора является индивидуальным документом, определяющим суть проекта. ТЗ гарантирует точность выполнения работ и сроки. Это абсолютно обязательный документ, если только вы не заказываете разработку студенту, а весь проект не стоит 5000 руб.
Откажитесь от доработок
Зачем вообще нужны какие-то доработки? В нормальном программном обеспечении все нужные вещи есть по умолчанию. В конце концов можно бесплатно подвести модель работы под ту, которая реализована в выбранной CRM-системе. Иначе потом будешь постоянно платить деньги за какие-то работы, которые никогда не закончатся.
Как на самом деле
Всё просто: если внедрение необходимо, его нужно реализовать. Но сделать это с умом, чтобы соблюсти баланс функциональности и стоимости внедрения, которое будет вам по карману и приведет к желаемому результату. Для начала необходимо определить главные задачи, без которых вы работать не сможете. В процессе тестирования решения (обычно это демо-версия или тестовый ключ, который можно заказать у вендора) вы должны открыжить по каждой из этих задач, выполняет ли их система и на каком уровне (отлично / хорошо / удовлетворительно). Если какие-то главные задачи реализованы недостаточно — проведите переговоры с вендором и уточните, можно ли их адаптировать под ваши требования. У вас родится первый и самый важный список доработок. Если вендор готов к необходимым доработкам, зафиксируйте их для себя и продолжайте дальше — составьте список недостающих возможностей, с которыми вы можете смириться, например, на первое время. Определите для себя период, за который вам нужно эти возможности реализовать. Переговорите с вендором, оцените техническую возможность, примерные сроки и стоимость. Составляйте техническое задание. Фактически, после этого вы будете иметь почти полное представление о том, подойдет ли вам данное решение или нет. Кроме того, у вас будет полный список необходимых доработок, оценка их стоимости и сроков реализации. Вы будете полностью вооружены и сможете принять взвешенное решение, в том числе при необходимости разбить внедрение на несколько этапов. Результат не заставит себя ждать.
Совет: При составлении требований не заставляйте вендора ломать структуру приложения так, чтобы требовалась глобальная переработка всей системы. Это всегда очень дорого и долго, а также не обеспечивает высокой стабильности полученного в итоге решения. Правильный путь — частично адаптироваться к базовым возможностям системы, а в местах, где адаптироваться невозможно — доработать ее под себя. Если такая двусторонняя адаптация невозможна — лучше поискать другую систему.
Держите развитие в узде, рост требует ресурсов
Не позволяйте компании расти. Рост — это новый набор персонала (та ещё адская история: опять эти собеседования, встречи, тесты...), закупки оргтехники и программного обеспечения, если вы разработчик — то это ещё и дорогие IDE, не дай бог ещё и офис расширять надо, с удалёнщиками ладить (эти вообще сплошь бездельники и кровопийцы). Но с другой стороны, когда раньше был один продажник, а теперь восемь, из них один начальник отдела, моя работа не изменится — мне все равно надо контактировать с одним начальником. Нафига тогда CRM-система? И так все вопросы можно решить, как раньше. Пусть за эффективность линейных сотрудников отвечает начальник отдела. Будут плохие продажи — не получит премию, сразу зашевелится.
Как на самом деле
В принципе, принудительное сдерживание роста компании не принесёт вам вреда — вы просто упускаете возможность занять больше места на рынке и больше зарабатывать. Опять же, есть риск оказаться неинтересным для сотрудников и потерять самых профессиональных и амбициозных. Масштабирование — это почти всегда благо, особенно, когда оно органичное, его не стоит упускать. Быстрый темп роста без потери эффективности возможен только в случае готовности бизнеса. И готовить сани нужно летом, ну то есть все условия должны быть созданы заранее — не бывает так, чтобы в среду вы были небольшой компанией, а в четверг проснулись средней. А значит, должно быть реализовано несколько аспектов: налажены и автоматизированы бизнес-процессы — так вы легко сможете масштабироваться и выдержать увеличение и усложнение задач; должны быть автоматизированы все ключевые процессы и управление (как минимум, это CRM или ERP, остальной набор ПО зависит от сферы деятельности); ваши сотрудники должны быть эффективными — то есть готовыми к нагрузке, изменениям, новым задачам.
Автоматизация решит большинство проблем, связанных с трудоёмкими процессами, рутинными задачами и вопросами, «разгребёт» часть документооборота. Кроме того, в определенный момент масштабирования бизнеса к руководителю приходит осознание того, что его головой начинают править цифры. Статистика. Разная. Для этого должны быть выстроены критерии, с помощью которых вы будете оценивать состояние вашего бизнеса, его точки роста или стагнации. А для их оценки необходимо иметь базовый элемент — сами измерения, без которых невозможно выполнить оценку. Т.е. с ростом бизнеса меняется и подход к его пониманию и управлению, меняются бизнес-процессы. Следовательно и CRM-система должна быть «живой», реагируя на меняющиеся условия бизнес-окружения. Грамотный руководитель должен это учитывать, если хочет идти выше.
Делайте свой софт, это 100% круче
Начинается эта история всегда одинаково. CEO и главбух рассматривают список предложенных систем автоматизации (например, CRM), считают, что это всё дорого и заявляют на всю контору: «А чё это мы покупать будем? Запилим свою CRM на коленке!» В этот патетический момент технический директор щупает бутылку коньяка в столе, HR тихо ох…ет (охает) от перспективы искать группу программистов «fullstack и подешевле», вдумчивые сотрудники подсчитывают, сколько переработок им предстоит из-за заседаний рабочей группы. Конечно, это всё сплачивает коллектив и ведёт его к единой цели — своей собственной CRM-системе. Вы потратите всего 5-7 лет, зато получите вполне себе работающий релиз 1.0, в котором уже можно вести клиентов, строить воронку продаж, формировать простые отчёты и выдавать красивую панельку с данными для генерального. Разрабатывая свою CRM, вы в полной мере ощутите все прелести разработки, узнаете кое-что о дизайне, интерфейсах, бэкенде и безопасности. Это несомненный плюс, особенно для технологических компаний — действительно, если вы небольшой интернет-провайдер или продавец сельхозтехники, почему бы вам не подтвердить свою технологичность?
Как на самом деле
Разработка собственного программного обеспечения, особенно уровня энтерпрайз, дорогой и ресурсоёмкий проект. Вы вложите очень много сил, денег, времени, нервов и на выходе через несколько лет получите систему автоматизации самого базового уровня (это касается не только CRM, экспериментируют и с другими типами корпоративного ПО). Нужно понимать, что CRM-система — это не просто планировщик задач. Это сложное сетевое инфраструктурное решение для коллективной работы команды людей. Те типовые решения, которые есть на рынке, создаются годами и развиваются десятилетиями, на их разработку тратятся десятки и сотни миллионов (и не всегда рублей). И если типовой продукт с кучей функционала можно купить в 1 день за 100 тыс. руб., а за пару месяцев и еще 100 тыс. руб. доработать то, чего в нем не хватает, то создавать подобную систему с нуля вам придется минимум 5 лет и совокупно потратить на это