Что лучше: коробка или кастом? Личный кабинет поставщика в ритейле

Всем привет, я — Антон Белов, управляющий собственник компании Tool-kit. tech. Мы создаем IT-системы, упрощающие жизнь бизнеса.

В прошлых видео мы рассмотрели, что такое SRM, как система помогает сделать обнординг поставщиков, управление заказами, отгрузкой и документооборот проще и доступнее.

Давайте теперь поговорим про то, на какие моменты стоит обратить внимание при внедрении SRM.

В большинстве случаев, у крупных компаний складываются индивидуальные бизнес-процессы по взаимодействию с поставщиками.

Как правило, у каждой компании своя цепочка согласований, свои форматы документов, договоров, счетов-фактур и другое. При этом часто возникает соблазн воспользоваться коробочной системой, организующей бизнес-процессы. К счастью, в большинстве смежных систем, таких как: PIM, CRM, BPM, существуют встроенные движки, позволяющие составить любой процесс.

Но в итоге, когда встаёт вопрос масштабирования бизнеса, система становится препятствием, и требуются дополнительные бюджеты и время на переделку.

Кроме этого в стандартных (коробочных) решениях большое внимания уделяется модели данных и моделлеру процессов, а не интерфейсу для пользователей, которые в этом процессе будут участвовать.

Излишняя универсальность таких систем приводит к низкой скорости их работы с одной стороны, а с другой — они все таки не могут удовлетворить все бизнес-требования заказчика разработки.

Получается такой парадокс: мы вроде бы взяли коробочное решение, но шаг влево или шаг вправо приводят нас к неоправданным тратам.

Представим, вам нужно организовать револьверное согласование какого-то шага процесса. Что это значит? Что каждый из 6 человек должен согласовать документ, иначе он отправится на предыдущую стадию. И вроде бы коробка позволяет такое сделать, но при обсуждении задачи начинают всплывать дополнительные подробности, двое из шести человек должны согласовать это последними, один может не согласовать, но процесс должен продолжиться. Все они должны получать регулярное уведомление, что они должны согласовать. Плюс информация о согласовании должна попадать в 1С.

И вот задача, которую можно было сделать коробкой превратилась в задачу, которую нужно разрабатывать, но при этом вы теперь должны учитывать весь код, который есть в коробке, часто, это от 30 000 и более строк. И вот задача на час, если у вас самописная система, превратилась в задачу на 2 дня, если у вас коробка.

И как я сказал выше, таких задач будет большинство, так как бизнес-процессы- уникальны.

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

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

Давайте теперь поговорим про одну из основных причин в пользу кастомной разработки.

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

Вы можете запихнуть в PIM-core процесс согласования документов вашего поставщика, но вам придется пустить его туда, а что он увидит, когда зайдет в систему, которая не предназначена для внешних пользователей:

Исходя из этого, давайте теперь разберемся как же правильно выбрать ответственного за разработку такого решения.

Прежде всего, необходимо помнить о компетентности разработчика. Не стоит связываться с теми, кто предлагает только одного менеджера вместо инженера. Ведь именно инженер должен быть главным в команде, которая будет внедрять систему. Он должен обладать всеми необходимыми знаниями и опытом для успешного завершения проекта.

Тут стоит отметить, что в команде, конечно же, есть место и для хорошего менеджера, и для хорошего аналитика, и для въедливого тестировщика, часто это может быть один человек.

Как же выглядит процесс разработки начиная от запроса и заканчивая внедренным решением?

Все начинается с того, что менеджер/аналитик и дизайнер вместе с заказчиком прорисовывают интерфейсы, обычно такой дизайн делается в фигме. Часто это кликабельный макет. Что значит кликабельный? Это значит, что когда вы в дизайне нажимаете на кнопку, ваш экран сдвигается на тот, который должен появиться при ее нажатии.

Таким образом получается иллюзия, что вы уже используете рабочую систему, хотя на самом деле фигма всего лишь двигает ваш экран между нарисованными элементами.

Такой способ отрисовки позволяет спроектировать и показать работу системы всем вовлеченным сторонам. Иногда в особо сложных процессах. Мы прибегаем к схематизацию через BPMN-нотацию.

BPMN — это графический язык описания бизнес-процессов, позволяющий человеку, который видит его в первый раз, понять его без лишних вопросов.

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

Это является практически готовым техническим заданием, то есть такой вот дизайн в фигме заменяет 40-страничное тз, написанное словами, что сильно экономит время как заказчика, так и исполнителя. А как мы знаем, время — это деньги.

Теперь вам должно стать понятно, почему в некоторых случаях выбор самостоятельной разработки решения под себя, является оптимальным, но здесь важно не превратить такое решение в монолитную систему.

Что такое монолит? Это такая система, которая объединяет в себя большое количество слабо-связанных между собой функций. Например у вас есть 2 бизнес направления, одно из них отвечает за продажу товара на полке вашего магазина, а другое за реализацию товара по схеме маркетплейса. Команды, которые работают по этим направлениям — разные, бизнес-процессы тоже различаются. Если вы все это заверение в одну систему, получится монолит.

Чем он плох? Во-первых, два разных заказчика (а команды, как вы помните, у вас разные) будут генерировать для команды разработки конфликтующие друг с другом задачи и вы не сможете их разделить, потому что система у вас будет одна и командам придется договариваться между собой.

Во вторых, есть правило, точнее даже закон в разработке, который гласит, что сложность внедрения каждой новой задачи возрастает по экспоненте, поэтому чем больше вы закладываете функционала в систему, тем больше времени и денег стоят ее доработки.

А теперь давай на секунду представим, что вы решили закрыть или полностью пересобрать полностью одно из двух направлений. Это неминуемо приведет к проблемам у команды разработки соседнего направления, если это монолит.

Поэтому мы всегда делим такие системы на сервисы, изолируя в них бизнес-процессы и упрощая тем самым разработку и поддержку.

Теперь, когда мы проговорили как устроена система, а именно то, что она разделена на сервисы, давайте поговорим про то, как эти сервисы обмениваются между собой данными.

Часто в крупных компаниях для этих задач используется ESB (Enterprise service bus) — сервисная шина предприятия. Такой подход более эффективен, чем попытка связать между собой сервисы и системы силами их внутренних команд. Почему так?

Ну во-первых, задача по интеграции это рутина, многим системам, которые нужно связывать: 1С и Битрикс24 по 15 лет и у них давно сформирован механизм для обмена сообщениями. Часто он по меркам разработчика бывает довольно архаичным, но никуда не денешься. Систему надо связывать и решать задачу связи, новой, современной, кастомной системы с протоколами 15-ти летней давности командам разработки дается нелегко.

Во-вторых, так как делают они это в первый раз, то соберут на этом целое поле граблей. Думаю, вы и сами не сторонники подхода изобретать велосипед.

Шинам данных тоже 15-20 лет и все это время единственной их задачей и смыслом существования было связывать между собой такие системы.

Вот по этому, мы сторонники подхода, при котором команда разработки отвечает только за разработку фич и собственного стандартного интерфейса для обмена данными, а отдельная команда интеграторов связывает их стандартный интерфейс со стандартным интерфейсом битрикса или 1С через ESB.

Еще одним Важным моментом при внедрении SRM-системы является необходимость озаботиться безопасностью и конфиденциальностью данных.

Система должна иметь надежные механизмы защиты информации и обеспечивать защиту от несанкционированного доступа и утечки ваших данных и поставщика.

Тут мы придерживаемся следующего подхода:

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

Тут мы обычно разделяем поддержку на 5 уровней. Для того, чтобы снизить ее стоимость и повысить эффективность ее работы. Как настоящие айтишники, начнем нумерацию с нуля.

L0 — уровень поддержки, отвечающий за психологическую помощь пользователю, его задача принять обращение, ну или выслушать и записать, если хотите, часто это может быть робот, а не человек.

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

Следующий уровень — L2. Это кстати тот уровень, на котором часто находится заказчик (product-owner системы). Задача этого уровня — обладая всей полнотой информации того, как система спроектирована и работает, решить проблему пользователя, не залезая в код системы. Кстати, на этом уровне хорошо видно, какое сейчас состояние системы, потому что следующий за ним уровень — это уровень разработки и если туда проходит слишком много однотипных задач, то это говорит о том, что пора писать сценарий или делать инструмент для уровня L1.

Теперь самое интересное — уровень L3, это разработчики, задача которых фиксить последствия. Они не занимаются внедрением новой функциональности, только устранением последствий.

А вот уровень L4 -это как раз уровень вендоров системы. Именно они решают задачу, ее доработки и развитие.

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

Для уровня L1 — это означает написание сценариев на самые частые проблемы, на уровне L2 поиск обходных путей для решения задачи через уже существующий функционал системы. Для уровня L3 — это постоянное производство инструментов для верхних уровней техподдержки, которые позволяют решать им проблемы пользователей самостоятельно.

Также, для уровня L2 одной из ключевых задач является написание корневых причин проблем, так называемых “руткозов”, к большому количеству проблем может крепиться одна корневая причина, и именно на этих коренных причинах должны быть сосредоточены уровни L3 и L4.

Ну и наконец, самый важный ритуал — это еженедельная встреча и аналитика того, какое количество у нас было обращений, у скольких из них установлена корневая причина и сколько корневых причин исправлено.

Именно борьба с корневыми причинами является основной задачей техподдержки.

Итак, поведем итоги. Мы с вами разобрались, что конкретно для SRM систем выгоднее делать их разработку под себя, потому что бизнес-процессы у компании сильно различаются. Для разработки важно на старте проработать существующие бизнес процессы и дизайн интерфейса для их исполнения. Важно не запихивать все в одну систему, чтобы не получился монолит, а разделить процессы по сервисам.

Сервисы лучше соединять, используя шину данных. Важно подумать про безопасность системы. Тут можно и нужно использовать внешние сервисы и внешнюю экспертизу. Ну и после запуска системы важно обеспечить процесс ее поддержки и развития.

Надеюсь что эта статья оказалась полезной для вас, ну а на сегодня это все, подписывайтесь на нас и оставляйте ваши вопросы в комментариях, мы с удовольствием ответим на них, спасибо, пока!