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 стоит разрабатывать самостоятельно — хотя бы для того, чтобы получить полный контроль над процессами и независимость от подрядчиков.