_1.webp)
Прошло чуть больше года с момента запуска нашей собственной CRM системы. Она прекрасно работает, мы намного лучше стали обрабатывать первичные заявки клиентов. Но речь сейчас не о ней.
Уже год как мы разрабатываем собственный торгово-складской блок, чтобы выставлять счета, делать отгрузки, учитывать заказы поставщикам и складские остатки. И с ним все оказалось не так все просто, как с CRM. В ходе разработки нам пришлось избавиться от некоторых розовых очков. Итак вот, что мы выяснили:
Открытие №1. Удобство интерфейса не может расти бесконечно. Оно вступает в противоречие с гибкостью системы.
Мы были очень горды собой, что придерживались сценарного подхода к реализации интерфейса. Если 1С и МойСклад учитывает закупку и продажу товара как две отдельные сущности, слабо связанные друг с другом, то мы очень давно придумали для себя понятие "сделка" и в одной сделке отслеживали путь товара от поставщика к нам и далее до клиента. С точки зрения удобства менеджера по продажам "сделка" сильно удобнее, чем раздельный учет "продажи клиенту" и "заказа у поставщика", когда речь идет о товарах с длительным сроком поставки.
По сути "сделка" оказалась "кентавром", одновременно объединяющим две разные сущности (закупку и продажу). Удобство для менеджеров по продажам обернулось кошмаров для разработчиков и, кроме того, очень низкой гибкостью при дальнейших изменениях системы.
Отбросив первый вариант разработки - чистого кентавра, мы перешли к созданию раздельных сущностей закупки и продажи, но при условии тесной связи между заказом поставщику и заказом клиента. Однако мы опять натолкнулись на кошмар сложности учета таких связей. Ведь заказ поставщику может идти на склад, а в это время товары из этого заказа надо будет резервировать за какими-то счетами для клиента. Получается, что каждый заказ поставщику может быть связан с несколькими счетами клиенту. И наоборот.
В итоге мы поняли, что путь тупиковый и решили принципиально развести заказ поставщику и заказ клиента. Логика хранения данных 1С здесь победила. Мы долго боролись с этой логикой, но в итоге к ней и вернулись.
Для учета связей между товарами в закупках и продажах мы теперь будем вести учет в разрезе каждой отдельной единицы товара (спасибо Сергею Елькину, что навел нас на правильный путь). Раньше мы учитывали не каждый товар в отдельности, а его название и количество. И была проблема как учесть товар в заказе поставщику, если из 5 единиц одного названия 3 единицы шли на склад, а еще по одной единице были зарезервированы за двумя счетами покупателям. При новой логике хранения данных проблема ушла. Теперь мы можем любую единицу товара из закупку связать с любой единицей товара из продажи.
Гибкость победила, да и интерфейс в итоге не сильно пострадает. Разве только менеджеру по продажам придется сделать лишний клик, чтобы понять когда прибудет товар для клиента по конкретному счету.
Открытие №2 (по сути, частный случай Открытия №1). Не существует идеального варианта хранения настроек в системе. Опять же возникает конфликт между скоростью изменений настроек и гибкостью системы.
Вот простой пример для иллюстрации. Чтобы каждый раз при создании заказа иностранному поставщику не выбирать нашу организацию, которая покупает товар, мы решили добавить преднастройку. Первая мысль - добавить преднастройку в карточку иностранного контрагента. Но с учетом того, что поставщиков у нас несколько, а выбор организации-покупателя подчинен строгой логике, мы задумались, что неплохо было бы добавить преднастройку для заказов в целом. Тогда при изменении логики выбора покупателя нам не придется заходить в карточку каждого отдельного контрагента и менять там настройки. Однако тогда мы потеряем в гибкости. Что если из общей логики надо будет сделать исключение? Тогда второй вариант преднастройки окажется ущербным. Вот и приходится выбирать в итоге - скорость против гибкости. И выбор должен быть сугубо индивидуален для каждого сценария.
Мы давно заметили, что все стандартные решения (будь то CMS сайта или SaaS CRM) всегда выбирают в настройках гибкость в ущерб скорости настроек. Теперь мы понимаем, почему это так. Иначе большинство их клиентов просто не могли бы настроить сущности так, как им нужно.
Точно так же становится понятным, почему остается большая ниша для индивидуальных разработок. В них есть возможность найти для себя оптимальный баланс между гибкостью системы и скоростью работы с ней. Например, мы редактируем контент на этом сайте (www.zenova.ru) значительно быстрее, чем делали бы это через стандартную админку какого-нибудь Битрикс CMS. В индивидуальной разработке есть возможность пожертвовать гибкостью там, где она не нужна и получить большой прирост в скорости работы пользователей системы.
Можно провести аналогию с золотым правилом механики. Или ты выиграешь в силе или в скорости. Нельзя выиграть одновременно там и там. Этот же принцип действует в разработке приложений. Или ты выигрываешь в гибкости системы или в удобстве/скорости пользования ею. Задача как всегда сводится к поиску оптимального баланса.
Где мы сейчас?
Несмотря на набивание некоторых шишек, мы полны оптимизма и перерабатываем ТЗ для создания торгово-складской системы. Сейчас уже без лишнего "интерфейсного выпендрежа". Все же мы четко поняли, что нельзя игнорировать сложность логики хранения данных в системе. Нужно правильно выстраивать баланс между логикой хранения данных в БД и интерфейсными плюшками. Загадывать по срокам не будем, но все же рассчитываем на ускорение дальнейшего движения. Ведь не зря же говорят, что за одного битого двух небитых дают.
Чтобы не страдать, пока будет готова новая версия системы, мы тем временем решили побаловаться созданием дополнительных надстроек для программы МойСклад, которой мы в настоящее время пользуемся. И здесь получилось по принципу "глаза боятся - руки делают". API дало нам возможность достать нужные данные из МойСклад и представить в удобной для себя форме. На первом этапе мы уже получили более удобную для себя аналитику движения складских остатков для планирования заказов на склад. На втором этапе будем "учить" систему распознавать "продажи в работе" и выводить их на отдельный экран для контроля своевременности движения товара клиенту.
Продолжение следует...
Автор - Руслан Загидуллин