10 этапов разработки собственного ПО для автоматизации процессов
Зачем ритейлерам разрабатывать ПО и что для этого нужно? Юлия Пшеничная, руководитель направления разработки WMS-систем в компании «Кактус», рассказывает о 10 этапах создания программного обеспечения для автоматизации процессов в сфере e-Сommerce.
В эпоху развития информационных технологий разработка собственного программного обеспечения — закономерный шаг для многих онлайн-ритейлеров. Сегодня в сфере электронной коммерции можно автоматизировать практически все процессы: создание заказов, их обработку и подтверждение, сбор и упаковку, контроль за доставкой и анализ аналитики. Компании разрабатывают собственные ИТ-решения не только для того, чтобы повышать эффективность бизнес-процессов и конкурентоспособность — некоторые из них впоследствии выводят такие продукты на рынок.
От идеи к созданию
1. Чтобы разработать программное обеспечение, стоит начать с анализа существующих бизнес-процессов и определения «узких» мест — это нужно для того, чтобы составить список требований к программному обеспечению.
Разберем на примере WMS — системы, с помощью которой можно контролировать все процессы, связанные с управлением складом:
● получать, обрабатывать и размещать позиции на складе наиболее эффективным образом;
● оперативно корректировать уровни запасов;
● автоматически создавать транспортные накладные, счета-фактуры и другие документы;
● распределять задачи и управлять площадками для хранения и погрузки.
Чтобы создать собственную WMS, мы постарались сделать так, чтобы команда разработчиков полностью погрузилась во все процессы. Наши ИТ-специалисты буквально «жили» какое-то время на складе, чтобы полноценно участвовать во всех операциях компании, собственными руками принимать и собирать заказы, проводить инвентаризацию и другие манипуляции. Мы замеряли все показатели, а затем проводили тестирования с альтернативными вариантами и составляли перечень доработок. Стояла задача детально описать все процессы, отрисовать схемы взаимодействий, а затем согласовать все с операционным и складским блоком.
2. Следующий шаг — определить цели и задачи, чтобы выяснить, какие процессы нуждаются в автоматизации и как это может помочь бизнесу зарабатывать. Например, перед нами стояла задача ускорить выполнение складских операций: от приема и обработки товаров до отгрузки и оформления возвратов.
3. Затем можно приступать к написанию плана развития, который будет включать все этапы разработки программ: от первых концепций до тестирования и внедрения в производство.4. Только после этого можно приступать к выбору архитектуры ПО — на этом этапе особенно важно определить то, как новое программное обеспечение будет взаимодействовать с уже существующими решениями, разработать структуру базы данных и пользовательский интерфейс.
Определяясь с архитектурой для системы управления складами (WMS) стоит брать во внимание тот факт, что она должна быть сделана на базе современных технологий, которые ИТ-сообщество считает перспективными — это позволит легко находить специалистов (или даже переманивать их из других компаний).
Стоит помнить, что WMS — это часть общей инфраструктуры, поэтому при создании нового ПО важно проработать протокол взаимодействия со смежными системами.В нашем случае мы соединяли WMS с OMS — системой, позволяющей управлять заказом на протяжении всего жизненного цикла: от его формирования до исполнения или возврата, а также с DLV — системой интеграции с курьерскими службами и с биллинговыми системами.
Что касается разработки пользовательского интерфейса, то тут все происходит по классической схеме: придумываются прототипы, затем они обсуждаются с операционным блоком и вносятся правки. Когда интерфейс готов, можно приступать к подготовке документации по взаимодействию с ним и его связи с API backend, различным кейсам применения и UX.
5. Следующий этап — разработка программного кода с учетом всех внутренних процессов компании, тестирование каждого компонента и всей системы в целом. Здесь важно убедиться в том, что программа работает правильно и соответствует требованиям.6. Затем наступает время финального «приемочного» тестирования, когда прототипы показывают сотрудникам. На основании их замечаний определяют перечень и приоритет доработок.
7. Лучшее заранее выделить ресурсы на доработку программного обеспечения — ошибки обязательно «вылезут». Практика показывает, что на исправление ошибок в коде после запуска может уходить до половины времени, затраченного на разработку.
8. После работы над ошибками выходим на финишную прямую — остается подготовить документацию. В нее стоит включить инструкцию по работе с ПО, руководство пользователя и другую справочную информацию.
9. Предпоследний этап — обучение и поддержка пользователей. Даже если изначально ПО создавалось для внутренних целей компании, затраты на разработку оправданы, если пользователи задействуют его функционал в полной мере. Задачи обучения могут взять на себя сотрудники компании — а еще советы по использованию ПО стоит включить в сам продукт.
10. Совершенствование ПО — это последний этап, который, как правило, повторяется неоднократно, особенно если компания решила продавать ИТ-решение как услугу внешним заказчикам. Всегда можно что-то улучшить — например, можно попытаться еще сократить время выполнения складских операций. Так, уменьшив каждую операцию на несколько секунд — например, упаковку товаров — можно сэкономить сотни часов труда операторов и как следствие затрат.
Про разработчиков и бюджеты
Во-первых, для всего вышеперечисленного нужны опытные программисты, способные создавать и поддерживать программное обеспечение. Например, в нашей компании отдел разработки состоит из тридцати человек. Из них над одной только WMS трудится порядка десяти сотрудников: разработчики фронтенд React.js, бэкенд Java (Spring), UI/UX-дизайнер и сотрудники, обладающие экспертизой в сфере складских операций.
Во-вторых, необходимо закладывать на разработку ПО серьезный бюджет. Чтобы примерно посчитать объем инвестиций, можно ориентироваться на минимальную среднерыночную зарплату команды из тимлида, фронтенда, двух бэкендов и дизайнера. При наличии экспертизы и опыта в разработке программного обеспечения на все уйдет около года.
Свое или чужое?
Разработка собственных решений — это всегда большой труд, требующий немалых затрат. Далеко не все компании могут себе позволить содержать полноценный ИТ-отдел, поэтому очень важно реально оценивать свои возможности и цели — да, кто-то может все сделать сам, но кому-то все же лучше взять готовое SaaS-решение (программное обеспечение как услуга). И это нормальная практика.
SaaS-решения— это облачная модель предоставления программного обеспечения, которая доставляет приложения конечным пользователям. Такой формат очень удобен и позволяет компаниям «купить» уже готовые WMS- и другие продукты, которые годами разрабатывались узкопрофильными специалистами, понимающими специфику ниши и потребности рынка.
И такие решения, действительно, отлично сработают если целью бизнеса является автоматизации смежных и вторичных процессов. Тем более, нередко SaaS-услуги обходятся гораздо дешевле, чем самостоятельная разработка сервиса, а в сфере электронной торговли заказчики внешних WMS очень часто заинтересованы в том, чтобы тратить меньше ресурсов на мониторинг изменений во взаимодействии маркетплейсов и курьерских служб.
Однако, если программное обеспечение — это ноу-хау компании и новшество, которое имеет потенциальную коммерческую ценность, то WMS стоит разрабатывать самостоятельно — хотя бы для того, чтобы получить полный контроль над процессами и независимость от подрядчиков.