CRM-системы: на самосвале за спичками

Возможно, у вас проблемы с парковкой перед домом, а может быть, вы твёрдо решили, что с завтрашнего дня в вашей семье должен быть только один-единственный автомобиль – универсальный, на все случаи жизни. Вы приступили к делу и начали составлять список пожеланий: количество мест – от 30 (для пикников на природе с друзьями), сантехнические удобства, включая душ и джакузи (для дальних поездок), грузовой кузов (для экономии на доставках стройматериалов на дачный участок), летняя беседка для чаепития (а вы попробуйте все 16 часов пути на курорт безвылазно сидеть в закрытом салоне!)… Облазив все известные вам автосалоны, вы всё-таки нашли подходящую модель: профессионально сконструированный гибрид автобуса, самосвала и лимузина – но вскоре поняли, что в большинстве случаев тратите десятки литров топлива и часы своего времени на прогрев двигателя и поездку за спичками в ближайший магазин. Какова вероятность, что после этого ваши взгляды на универсальность как неоспоримое достоинство любого изделия – могут слегка измениться?

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

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

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

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

Впрочем, самое интересное при общепринятом подходе начинается дальше.

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

Затем выясняется, что вся эта роскошь, включая дополнительные модули, нуждается в предварительной настройке под конкретный бизнес-процесс (даже несмотря на то, что изначально под него была якобы заточена). Для настройки требуются услуги специалиста – но, разумеется, не просто какого-то там вообще специалиста, а именно конкретно грамотного знатока приобретённого предпринимателем программного комплекса. А как становятся знатоком? А очень просто: проходят курсы по сертификации и получают сертификат специалиста. А услуги сертифицированного специалиста недёшевы. А если специалист, но без сертификата – то вообще неизвестно, какой он там специалист, почему не получил сертификат и не поломает ли всю систему при первом же удобном случае.

Ну и напоследок обнаруживается, что приобретённая система начинает тупить и тормозить уже на пятой тысяче ассортимента, потому что «сюда надо было добавлять код товара, а не комментарии о поставщике» и «а чего вы хотите, если у менеджера одновременно открыто десять окон с одним и тем же прайсом?!». И в завершение – в лучшем случае компоненты программного комплекса вручную допиливаются всё тем же сертифицированным специалистом (в финале фактически представляя собой ту же самую «кустарщину», только не саму по себе, а в роли «костыля» в недрах механизма программного комплекса), а в худшем – персонал компании ежедневно теряет колоссальное количество времени на ожидание отклика от зависающих вкладок или окон.

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

Причина явления – неотъемлемый, априорный атрибут готовых решений: универсальность. Универсальность везде, во всём и всегда. Услужливая до умопомрачения: «врач примет вас через десять минут, но если вы торопитесь, то подождите полчаса, пока я узнаю, не сможет ли кто-то принять вас побыстрее». Можно согласиться, что в некоторых случаях универсальность – полезное свойство, но – доведённая до абсолютного абсурда – она превращается в крупный недостаток.

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

Фокус в том, что у разработчиков типовых программных решений (CRM, CMS) и «самописцев» – кардинально разный подход к созданию программного продукта: если первые создают максимально универсальный продукт и обвешивают его сверху донизу всевозможными модулями на все случаи жизни – то вторые, как правило, конструируют лишь минимально необходимый для работы проекта код и наращивают его лишь в случае необходимости. И если самописный проект сконструирован грамотно – то работать он будет в десятки, а то и в сотни раз быстрее проекта на CRM даже на старых версиях языка, не говоря уж о новых (кстати, скорость загрузки страниц интернет-сайтов – один из факторов ранжирования поисковыми системами, если кто не в курсе – у Google даже соответствующий сервис для этого имеется).

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

Если вы отчётливо понимаете, что вам требуется, не согласны платить за то, в чём у вас нет необходимости, и предпочитаете избежать будущих проблем с производительностью на самом раннем этапе проектирования – добро пожаловать на сайт МедиаПандора, поможем. Ну а всем остальным рекомендую не задумываясь выбрать типовую CRM.