Система управления заказами на сайте. Разработка системы личных кабинетов для клиентов компании

Рано или поздно любой успешно работающий бизнес увеличивает поток заказов. Обработка заказов становится более трудоемкой, и требуетя совершенствование системы управления заказами.

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

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

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

Представим бизнес, который продает на потоке некую продукцию или оказывает услуги.

В простом случае заказы можно вести в тетради, где мы указываем что продали, кому, когда, по какой цене. Улучшенный вариант - это ведение той же тетради, но в Excel файле. Еще более продвинутый вариант, вести тот же Excel в облаке, например, на Google Disk. В этом случае с файлом одновременно могут работать несколько людей.

Эти подходы имеют свои существенные недостатки, который мы описали в отдельной статье.

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

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

Так может выглядеть страница заказа.Список заказов в личном кабинете

В заказе могут быть некие поручения, задачи и комментарии к заказу.

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

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

Время - деньги. Чем быстрее заказ проходит свой жизненный цикл, тем меньше шансов, что сделка сорвется, меньше требуется ресурсов (помним закон Паркинсона: "Работа занимает все отведенное для нее время").

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

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

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

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

Системы на основе Excel дают слишком много свободы оператору, поэтому и стандарты сложнее соблюдать и контролировать.

Система обработки заказов позволяет повысить точность в распределении задач сотрудников относительно заказа.

Каждый выполняет строго отведенную роль в процессе обработки заказа. На практике этого не так легко добиться, и требуется итеративное приведение процесса к нужной Лыжне (реализация базового процесса и постепенное закручивание гаек).

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

Можно составить цифровую картину, как в реальности работает ваш бизнес в плане обработки заказов. Эта информация будет максимально объективна. Система просто фиксирует все события по заказам и действиям сотрудников относительно заказов.

Множество структурированных данных о заказах позволит получить массу интересной информации по заказам:

Понимание этих вопросов повышает вероятность принятия правильных решений.

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

Сама система становится ключевым объектом.

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

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

Удаленное взаимодействие с клиентом дает множество преимуществ. Можно параллельно обрабатывать сразу несколько запросов. Один оператор может взаимодействовать через чаты сразу с несколькими клиентами. Не требуется время на перемещения и задержки, связанные с пробками, очередями, опозданиями.

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

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

Это дает возможность обрабатывать множество обращений в единицу времени.

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

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

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

При ручной обработке сотрудник может обработать 5 клиентов в час, а через систему это может быть 1000 (т.к. нет жесткой привязки клиента ко времени сотрудника).

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

Если у системы есть регулярное обслуживание, делаются бекапы. Это позволяет с уверенностью сказать, что данные не потеряются. В случае возникновения аварии можно восстановить прошлую копию (за прошлый день).

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

В случае с Excel файл очень легко повредить данные - выделить все и удалить, случайно вставить большой кусок информации не туда.

В случае с бумажными документами - они могут сгореть, их могут вынести, вырвать некоторые листы, на них могут пролить кофе.

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

Любой отчет нужен для принятия определенных решений. Подумайте, какая информация вам нужна для принятия решений (и какие это будут решения).

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

Система позволяет выявлять проблемные, зависшие заказы.

Можно отслеживать дубли по заказам или клиентам.

Строгие форматы данных позволяют минимизировать ошибки операторов при занесении информации (например, внесение телефона вместо email).

Имеет смысл сразу представлять в общих чертах нюансы по использованию системы обработки заказов. Это позволит избежать неприятных казусов в ходе эксплуатации системы.

Именно процесс продажи и обработки заказа может быть конкурентным преимуществом компании. Будет неправильно ломать свой процесс в угоду некой системы.

Если система негибкая, и ее сложно менять, то любые инновации по процессу обработки заказа будут тормозиться. Система должна позволять быструю адаптацию под изменяющиеся реалии бизнеса.

Какие это могут быть изменения?

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

Это позволит оперативно управлять некими процессами и вносить коррективы.

Если система работает через браузер через Интернет, то она доступна практически везде и всегда. Это дает вам возможность физически находиться где угодно, но при этом сохранять оперативную связь со всей бизнес-системой.

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

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

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

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

Лишние доступы повышают бизнес-риски. Если человек работает только с заказом А, то ему не нужно ничего знать о заказе Б. Руководитель отдела продаж может знать все о продажах, но не нужно давать ему информацию о деталях производства.

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

В системе Falcon Space это делается за счет ролей + на уровне прописывания доступа к объекту для конкретного пользователя на SQL. Это позволяет очень гибко задавать разграничение доступа для людей, работающих в системе.

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

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

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

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

Делайте интерфейс системы максимально простым (со временем он все равно станет сложным из-за новых внедрений). Это позволит снизить порог входа для пользователей системы и уменьшит количество ошибок операторов.

Система должна позволять находить временные издержки. Это не просто инструмент учета данных, но инструмент учета времени.

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

Система обработки заказов должна позволять фиксировать любые временные интервалы при изменении состояния (статуса) любого объекта (заказа, заявки на склад, этапа проекта и т.д.). Ни одна готовая коробочная система не сможет этого дать по умолчанию. Это ваш уникальный опыт и способ работы с временными издержками, специфичными для вашего бизнес-процесса обработки заказов.

Метрики по умолчанию в системе не годятся. В ходе работы будет возникать необходимость получения узких, нетривиальных метрик, которых скорее всего не будет среди начального набора.

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

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

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

Заказ существует не в вакууме. Его обрабатывают различные люди, выполняющие свою часть работы по исполнению заказа. Менеджеры готовят КП. Инженеры делают техническую оценку проекта. Юристы согласуют договор. Бухгалтер выставляет счета и фиксирует оплаты, склад отгружает, логист обеспечивает комплектующие заказа.

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

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

Новый - В обработке - Принят - Доставка - Закрыт

Клиент:

Менеджер:

Оператор:

Сайт менеджер:

Стандартную схему выполнения заказа можно представить следующим образом:

Лид (Интерес) - Запрос КП - КП - Договор - Оплата - Производство (и комплектация) - Поставка - Закрытие документами - Сервис.

Есть некий потенциальный клиент, который оставляет заявку на возможную продажу (т.е. проявляет интерес). Это еще далеко не заказ, но уже создается заявка, которая является прообразом будущего заказа.

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

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

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

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

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

В нашем случае КП готовится в CRM и затем выгружается в виде Excel файла для клиента и передается по почте. Пример шаблона.

Заключение договора, оформление бумаг, обмен бумагами, отметка факта получения документов.

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

Необходимо получить оплату по заказу. Этот факт фиксирует в системе одна из ролей (например, бухгалтер или менеджер).

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

Если это не так, то можно сделать просто признак заказа оплачен или нет, но при этом не делать отдельный статус (например, вы можете сразу перевести в статус Производство еще не оплаченный заказ и начать над ним работу).

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

Товар или результат оказания услуг необходимо поставить клиенту. Зафиксировать факт поставки. Если поставка сложная, то можно дополнительно создавать заявки на транспортировку внутри системы, либо создавать заявки во внешние системы (например, создавать заявку в транспортной компании по API).

После выполнения всех работ заказ необходимо подкрепить закрывающими документами, например, актом выполненных работ. Обязательно занести артефакты в систему. Это может быть скан подписанного документа.

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

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

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

Задержки могут иметь систематический характер. Наша задача - понять, где задержка, в чем причина возникновения и как можно ее нейтрализовать.

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

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

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

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

В качестве артефакта может выступать созданный документ (КП), скан документа (акт), фото переписки, голосовая запись, скан отзыва клиента.

Необходимо варьировать объемом уведомлений. Слишком много малозначимых уведомлений - плохо. Люди просто перестанут на них обращать.

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

Уведомления типа "У вас много открытых задач" не очень помогает. Оно просто усиливает стресс человека, и он меньше будет обращаться к этому инструменту.

Каждое действие по заказу логируется. Сменили статус - это записалось в лог. Клиент скинул дополнительный файл - тоже запись в логе.

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

Некоторые элементы обработки заказа можно автоматизировать. Это уменьшит нагрузку на персонал и уменьшит количество возможных ошибок и задержек.

Постепенно все, что возможно надо автоматизировать. Сначала заказ может создавать менеджер в системе, но постепенно можно внедрить кабинет клиента, и он сам будет создавать себе заказ.

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

Клиент оформляет заказ в личном кабинете, менеджер обрабатывает, выдает информацию по заказу в строго типизированном виде, клиент через ЛК подтверждает параметры.

Дополнительное общение может потребоваться только в случае нештатных ситуаций или проблем.

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

Менеджер является центральным звеном в системе и координирует все процессы по заказу.

Основной функционал для менеджера - списки заказов и процесс обработки заказа.

Директора, как и НОП, интересуют общие метрики продаж. Также его могут интересовать проблемные места: где возникают проблемы, рекламации, задержки и потери (возвраты).

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

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

Главный функционал - он может самостоятельно формировать заказ и давать по нему обратную связь. Это уменьшает нагрузку на персонал компании.

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

Читайте статью про создание Клиентского сервиса на примере личного кабинета посетителя отеля или курорта.

Это служебный кабинет для обслуживания системы.

Администратор меняет настройки системы, добавляет и блокирует пользователей, управляет структурой каталога, модерирует данные (если необходимо).

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

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

Методы API делаются под каждую систему отдельно. Это может быть создание заказа, получение заказа, загрузка каких-то данных по заказу, получение уведомления.

API может быть, как со стороны системы, так и со стороны клиента. Т.е. система при наступлении определенного события будет вызывать метод АПИ внешней системы (например, выполнять определенный GET или POST запрос на внешний адрес).

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

Альтернативный вариант - это подготовка документа счета для последующей оплаты клиентом в ручном режиме.

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

Пример каталога в нашем демо

Каталог может содержать категории, фильтры, а также различные способы отображения товаров.

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

Это некая тикет-система, позволяющая обрабатывать вопросы пользователей: как клиентов, так и менеджеров.

Смысл такой системы не только в помощи пользователям, но и в улучшении самой системы.

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

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

Сюда же можно отнести и систему ремонта, если мы используем некоторое оборудование, задействованное в обработке заказов (либо суть заказа - аренда некоего оборудования).

Если заказ заключается в создании чего-то, то нужен блок Производство, где фиксируются основные моменты по выполняемому заказу.

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

Этот блок может быть, как очень простой (отметка Производство завершено), так и целый блок с множеством ролей, когда весь процесс производства выполняется по шагам в системе.

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

Финансовый блок позволяет отслеживать затраты, вести отчеты БДДР, БДР. Отслеживать платежи.

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

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

Личный кабинет в этом плане позволяет аккумулировать накопления клиента. Можно выводить его процент скидки, его бонусы, его принадлежность неким клубам (пример -IKEA Family).

Читайте более подробно о Система лояльности в личном кабинете

Можно очень тонко персонализировать работу с клиентом (но работает с клиентом не менеджер, а система в целом). Также можно стимулировать клиента делать то, что выгодно системе через награду бонусами, которые можно конвертировать в продукцию компании.

Личный кабинет клиента позволяет в ненавязчивой форме внедрить сбор обратной связи. Например, после каждой покупки просьба оценить заказ. Если меньше 4, то спросить кратко, что не так.

И все это без надоедливых звонков. Захочет ответить - проголосует. Не захочет - проигнорирует. Хороший момент для вовлечения клиента через баллы: начислить баллы (за голосование, к примеру) и дать возможность их потратить на что-то полезное.

Тем больше у вас будет возможностей по более плотной работе с клиентом.

Если заказ движется по статусам, то люди в системе двигаются от задачи к задаче.

Вы можете связывать различные статусы заказа с различными задачами. Можно это назвать заявками.

Заказ сформирован? Менеджер ставит задачу (или создает заявку) на его транспортировку.

Задачи могут быть как привязаны к чему-то (заказу, проекту, клиенту), так и просто быть сами по себе (проработать конкурента в сети).

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

Как определиться какой тип системы управления заказами подойдет? Предлагаю следующую схему.

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

Если же такой системы на примере нет, то переходим к следующему варианту.

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

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

Этот вариант предполагает проектную часть (т.е. адаптацию решения под процессы компании). Следовательно, он более дорогой чем, покупка готового решения. Однако, это ни в какое сравнение не идет по стоимости с 3 вариантом - разработка системы с нуля под свои нужды.

Главные преимущества этого подхода:

Основной минус - система налагает свои архитектурные ограничения (именно они позволяют добиться громадного прироста по сравнению с разработкой с нуля).

Это Fullstack разработка системы с подключением целой бригады программистов, дизайнеров, аналитиков, тестировщиков.

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

Главные минусы разработки с нуля:

Наша платформа Falcon Space и ее решения - это второй вариант, где мы готовим множество готовых к употреблению кирпичиков из которых собирается новая система. Эти кирпичики можно гибко комбинировать за счет использования SQL. Вся доработка ведется прямо в кабинете. Это позволяет делать быстрые изменения в системе.

Тестовый стенд платформы Falcon Space. Как выглядят элементы и возможности системы.

Все возможности веб-платформы описаны в каталоге возможностей. Возможности могут быть задействованы через SQL.

У платформы очень подробная документация.

Для технического сопровождения и развития системы надо знать всего лишь 2 популярных технологии:

В этом разделе обсудим как создать свою систему управления заказами по шагам.

Мы называем это концептом проекта. Создайте базовое описание системы своими словами, без технических терминов. Более подробно

Там же вы найдете шаблон концепции проекта.

На базе концепта можно сделать первичную оценку и получить КП. Это даст вам ориентир по срокам и стоимости внедрения первой версии программы.

Чем точнее начальное описание системы, тем точнее будет оценка проекта.

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

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

Подробнее про создание ТЗ

После написания ТЗ происходит детализация оценки, и именно она является основой для дальнейших этапов до внедрения первой версии программы.

Создается тестовый стенд, и на нем постепенно появляются новые кабинеты, новые страницы и функции на них.

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

Реализация первой версии программы обычно занимает 1-2 этапа (1 этап - это около 3-4 недель).

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

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

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

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

Система может быть очень простой, например, это просто таблица заказов и страница заказа. Рассчитана для одной роль менеджера.

А может быть очень сложной - много ролей в системе. Согласование деталей по заказу. Подготовка документации. Витиеватый путь заказа по статусам. Сложная бизнес логика по автоматическим действиям при смене заказов.

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

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

Почему именно телеграм, а не вацап, Viber?

Во-первых, у телеграм гораздо все лучше обстоит дело с API (широкие возможности, низкий порог входа по условиям).

Во-вторых, в нашей платформе интеграция с ботом Телеграм идет из коробки! Для управления ботом надо знать только SQL подробнее.

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

Вы можете хранить документы на Google Disk и прямо из кабинета редактировать их в интерфейсе Excel таблицы или Word документа.

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

Все это возможно реализовать на базе нашей веб-платформы.

Демостенд работы с Google Drive

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

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

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

Важно, чтобы система могла иметь возможность интегрироваться по API с любыми системами.

Платформа Falcon Space имеет универсальный API, который работает через HTTPS GET/POST запросы в формате XML, JSON. Вся настройка API осуществляется также через SQL.

Подробнее про API Falcon Space.

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

Установка KPI явно показывает направление, куда должна двигаться компания.

KPI может стать основой для системы премий и стимулирования сотрудников.

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

У всех есть телефон. И надо полагать, что для оперативной информации люди будут заходить в систему именно с телефона.

Итак, пользователь набирает адрес сайта, вводит логин и пароль, и попадает на свою панель - дашборд.

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

Также он может посмотреть уведомления по системе. Критичные отмечены красным. Некритичные синим.

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

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

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

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

Систему нужно строить под процессы, а не наоборот. Бизнес будет меняться, а система должна поспевать за ним.

Идеал подобного процесса:

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

Начните с описания концепта проекта: какие возможности будут в системе, какие роли будут, какой будет жизненный цикл заказа. Это станет отправной точкой по созданию своей системы управления заказами.

Источник: