Интеграция сервисов

Часть 1: CRM для ERP

Часть 2: Роботизация бизнес-процессов (в этой публикации)

Часть 3: Волшебные интерфейсы и оживление железа

Часть 4: Личные кабинеты, чат-боты и dream team

Роботизация бизнес-процессов на примере закупок (2 кейса)

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

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

Какие подготовительные этапы были выполнены в ERP до роботизации бизнес-процессов

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

Кейс #1: Роботизация процесса проверки поставщиков

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

В одном процессе участвуют 3-4 сотрудника из разных подразделений:

ВАЖНО!Чтобы не только правильно выполнялась процедура проверки, но вовремя запрашивалась и поступала информация от поставщиков, вовремя выполнялись и передавались задачи между всем участниками процесса проверки, включая поставщиков.

Для роботизации процесса проверки поставщиков в ERP мы связали в одну систему следующие компоненты:

• ERP-система (рабочее место сотрудников).

• Сайт компании (интеграция с ERP и сервисом DaData.ru).

• Почта Gmail (интеграция с ERP и сайтом).

• Сервис DaData.ru (интеграция с сайтом и ERP).

• Сервис 1С:Контрагент (интеграция с ERP).

На сайте компании разработана форма для самостоятельного заполнения контрагентом.

Для простоты заполнения к форме сайта подключен сервис DaData.ru - это и заполнение поле из общедоступных справочников и автоматическое заполнение связанных полей.

Пример формы на сайте для заполнения поставщиком

Все формы на сайте адаптивные, можно легко заполнить на смартфоне.

Пример адаптивной формы на сайте для заполнения поставщиком

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

Пример формы документа проверки поставщика в ERP

Робот автоматически отклоняет проверку контрагентас отрицательным результатом по 10 признакам, и одновременным уведомлением по email поставщика о причине.

Проверка контрагента в ERP автоматически не пройдена

1 - Робот автоматически устанавливает отрицательный статус проверки и завершает бизнес-процесс проверки.

2 - Робот автоматически определяет причина не прохождения проверки, и автоматически отправляет контрагенту письмо с причиной не прохождения проверки.

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

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

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

Пример задачи, которую получает сотрудник на своем рабочем месте в ERP

Таким образом,робот автоматически ставит задачи разным сотрудникам(или ролям) при переходе бизнес-процесса проверки на разные этапы.

Пример истории задач сотрудникам при проверке поставщика

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

Пример настроек робота в ERP для бизнес-процесса проверки поставщиков

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

Сотрудник выявил несоответствия при проверке

Контрагент получает автоматическое письмо по emailдля устранения выявленных замечаний:

1 - Замечание по каждому документу.

2 - Уникальная ссылка с ограниченным сроком действия.

Робот автоматически отправляет email поставщику со ссылкой для повторного предоставления документов

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

Пример формы на сайте для повторного запроса документов

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

Пример истории почтовых писем от робота по одной проверке поставщика

Все шаблоны автоматических писем настраиваются в ERP (в пользовательском режиме).

Пример настройки почтовой подсистемы для робота проверки поставщиков

Плюсы роботизации бизнес-процесса проверки поставщиков:

1. Из процесса проверки исключен один сотрудник - менеджер по закупкам.

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

2. Поставщики самостоятельно предоставляют данные через сайт.

Высвобождается время у менеджера по документообороту для запроса документов по email, и у поставщика для выяснения вопросов и пересылки писем.

3. Робот автоматически проверяет поставщиков по 10 признакам.

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

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

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

5. Робот автоматически пишет письма поставщикам.

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

6. Не нужно увеличивать штат сотрудников при увеличении числа поставщиков.

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

7. Новые поставщики приходят самостоятельно через сайт компании.

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

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

Настройки и функционал робота проверки статуса ликвидации организаций

Кейс #2: Роботизация процесса запроса КП у поставщиков

Процесс сбора, обработки и согласования коммерческих предложений не менее трудоемкий, чем процесс проверки поставщиков:

• Поиск поставщиков и подрядчиков.

• Запрос коммерческих предложений и их сбор.

• Сравнение предложений и выбор наилучшего поставщика.

• Подготовка аналитической записки и согласование с руководителем.

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

Для роботизации процесса запроса и обработки коммерческих предложений в ERP, мы связали в одну систему следующие компоненты:

• ERP-система (рабочее место сотрудников).

• Сайт компании (интеграция с ERP).

• Почта Gmail (интеграция с ERP и сайтом).

Рабочее место менеджера по закупкам в ERP с функционалом запроса КП через сайт

На сайте разработана динамическая форма для заполнения поставщиком коммерческого предложения:

1. Условия оплаты (налогообложение, цены с НДС или без, ставка НДС,наличие отсрочки и размер аванса).

2. Условия поставки (способ и срок доставки, наличие и срок гарантии).

3. Товары к поставке (цены, особые условия гарантии, сроков поставки или аналоги).

Пример формы на сайте для заполнения КП поставщиком Пример адаптивной формы на сайта для заполнения КП на смартфоне

Важно!Чтобы поставщик не тратил время на подготовку формы коммерческого предложения, ее можно:

• Скачать уже заполненную прямо на сайте.

• Распечатать, поставить подпись и печать.

• Отсканировать и загрузить на сайт.

Пример заполненной формы коммерческого предложения от лика поставщика

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

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

После окончания срока приема предложений, в ERP автоматически формируется аналитическая записка.

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

Аналитическая записка, сформированная роботом в ERP

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

Мы разработали и других роботов, которые работают в режиме 24/7 и облегчают жизнь.

Спасибо, что дочитали до конца!

Задавайте вопросы, постараюсь на все ответить.

Часть 1: CRM для ERP

Часть 2: Роботизация бизнес-процессов

Часть 3: Волшебные интерфейсы и оживление железа

Часть 4: Автоматические личные кабинеты и чат-боты (в этой публикации)

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

Комплекс систем автоматически работает 24/7 в режиме real-time и полностью реализован за 1,5 года. Хабом является корпоративная ERP-система.

Автоматическая система управления заказами - от создания заказов клиентов, до отгрузки на заводе и доставки

1. Клиенты оформляют заказы в личном кабинете клиента.

2. Заказы из личного кабинета автоматически попадают в ERP-систему.

3. По заказам клиентов в ERP автоматически формируются задания на перевозку.

4. Задания на перевозку в ERP автоматически распределяются между перевозчиками.

5. Заявки на перевозку из ERP автоматически попадают в личный кабинет перевозчика.

6. Перевозчики автоматически из ERP получают уведомления в чат-боте Telegram или по SMS о новых заявках в личном кабинете.

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

8. Водители автоматически из ERP получают уведомления в чат-боте Telegram о новых заявках.

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

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

11. Продукция отгружается на заводе, машины покидают территорию завода и выполняют доставку клиенту.

12. Клиенты автоматически из ERP получают серию уведомлений в личном кабинете, чат-боте Telegram или по SMS об изменении статуса доставки продукции.

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

А теперь подробнее о том, что для этого было сделано...

Личный кабинет перевозчика, распределение заявок и торги, чат-бот для уведомлений в Telegram

Напомню, что завод отгружает ~ 2 млн. тонн продукции в год, из них ~ 50% составляют отгрузки грузовым автотранспортом, что составляет ~ 40 000 рейсов в год.

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

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

Контур системы управления зданиями на перевозку включает 4 подсистемы:

1. ERP-система (формирование заявок и распределение между перевозчиками).

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

3. Чат-бот для перевозчиков в Telegram (мгновенные уведомления о новых заявках, торгах и опозданиях водителей).

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

Автоматическое распределение заявок между перевозчиками в ERP

В основе алгоритма автоматического распределения заявок между перевозчиками 3 базовых критерия:

• Квота перевозчика (отношение количества транспортных средств перевозчика к общему количеству транспортных средств всех перевозчиков).

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

• Рейтинг перевозчика (выполнение заявок и отказы от выполнения за последние 30 дней).

  Каждой заявке в ERP автоматически присваивается количество баллов от +1 до +4 (срочные заявки и заявки в дальние регионы получают максимальный балл). При отказе перевозчика от заявки баллы автоматически снимаются от -1 до -4. Рейтинг перевозчика это сумма баллов за последние 30 дней пропорционально количеству транспортных средств.

• Общая загрузка перевозчика (процент загрузки транспортных средств перевозчика за последние 30 дней).

  Общий процент загрузки заявками перевозчика за последние 30 дней по отношению у другим перевозчикам за тот же период.

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

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

Ежедневно по расписанию 3 раза в день, по заказам клиентов, роботом в ERP автоматически формируются задания на перевозку: 2 раза в день (утром и вечером) задания автоматически распределяются между перевозчиками, 1 раз днем задания попадают на торги.

Личный кабинет перевозчика и торги на сайте

Личный кабинет представляет собой пользовательский интерфейс и не хранит в себе данные. Обмен с ERP-системой выполняется через веб-сервис, API реализовано на стороне ERP.

Лайфхак: Правило оформления левого верхнего угла сайта личного кабинета

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

Лайфхак: Используйте числовую индикацию пунктов главного меню Личный кабинет перевозчика - главная страница

Сайт личного кабинета перевозчика полностью адаптивен для работы на смартфонах и планшетах (сейчас это 50% пользователей).

Примеры других страниц личного кабинета перевозчика

Общая логика работы перевозчиков с заявками в личном кабинете:

1. Мои заявки

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

2. Общие заявки

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

3. Заявки на торгах

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

   Все ставки перевозчиков по заявкам автоматически поступают в ERP. Через 30 минут после начала торгов робот в ERP определяет наилучшие ставки и распределяет заявки с торгов на перевозчиков по тем ставкам, которые они сделали в личном кабинете. Это дает существенную экономию по тарифам на доставку - до 20%.

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

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

Тот случай, когда перевозчик торгуется за заявку сам с собой

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

В данном случае перевозчик мог снизить тариф всего на 1 рубль и гарантированно получить заявку с торгов, так как кроме него больше никто ставок не делал. Но делая "слепую" ставку перевозчик снижает тариф на 138 рублей (11,15%).

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

Чат-боты в Telegram для перевозчиков и водителей

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

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

Личный опыт: Правила оформления текстов уведомлений в Telegram Пример различных уведомлений перевозчиков в чат-боте Telegram

Почему я не сделал мобильное приложение для перевозчиков?

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

Полнофункциональное мобильное приложение, интегрированное в нашей ERP-системой, предложила реализовать только одна компания. Стоимость 10 млн. руб. "под ключ" превышала весь мой годовой ИТ-бюджет на разработку в 2,5 раза.

Другие предложения составляли от 1 до 5 млн. руб. и мы самостоятельно должны были найти интегратора, который за отдельную стоимость "подружит" мобильное приложение с ERP-системой.

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

Разработка личного кабинета перевозчика на сайте, интегрированного с ERP-системой и двух чат-ботов в Telegram в сумме составила всего около 500 тыс. руб.

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

Быстрая разработка чат-ботов, которую мы используем

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

Логика чат-бота разрабатывается на стороне ERP, а встроенный модуль позволяет быстро настроить интеграцию с зарегистрированным ботом Telegram через API-ключ (токен). Для обмена ERP-системы с Telegram используется развернутый на нашей стороне веб-сервис.

Пример сценария чат-бота для водителей в интерфейсе ERP-системыПример настроек подключения чат-бота в интерфейсе ERP

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

Мессенджер чат-ботов в интерфейсе ERP-системы

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

Автоматическая регистрация нового пользователя в чат-боте Telegram

1. Новый водитель нажал в чат-боте команду СТАРТ и получил мгновенный ответ.

2. Водитель написал в чат-боте номер своего телефона и получил мгновенное приветствие.

3. Водитель нажал в чат-боте команду Я - ПРИБЛ НА ПОГРУЗКУ и получил мгновенный ответ.

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

Как обеспечить работу сервисов 24/7, когда тех.поддержка работает 8/5

Сотрудники линии тех.поддержки работают в режиме 8/5. При работе систем и сервисов в режиме 24/7 мы обнаружили, что веб-сервисы могут молча "отвалиться", а на стороне сервера этого не видно. Чтобы оперативно узнавать об этом, мы разместили на нашем основном сайте небольшой скрипт, который каждые 5 минут опрашивает состояние веб-сервисов.

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

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

Личный кабинет клиента, чат-боты в Telegram для уведомлений и согласований

В нашей компании всего 6 менеджеров по продажам. 3 менеджера обеспечивают 80% продаж, что составляет ~ 1,6 млн. тонн продукции в год.

КАК БЛО (ручной процесс):

Клиент >отправка заявки по email> Менеджер по продажам >создание заказа по заявке> ERP-система >согласование доставки по заказу> Менеджер по логистике >отправка заявки на доставку по email> Перевозчик >передача информации по телефону> Водитель

Большое количество участников процесса внутри компании. Большое количество коммуникаций между всеми участниками процесса (по телефону, по email, в мессенджерах, лично).

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

КАК СТАЛО (автоматический процесс):

Личный кабинет клиента >заказ клиента> ERP-система >заявка на доставку> Личный кабинет перевозчика >заявка на рейс> Личный кабинет водителя

Участие сотрудников компании сведено к минимуму (только при нештатных ситуациях). Коммуникации между всеми участниками процесса выполняет ERP-система (задачи, уведомления, обратная связь).

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

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

Личный кабинет клиента на сайте, интегрированный онлайн с ERP

Личный кабинет разработан на платформе "1С-Битрикс". Интеграция с 1С реализована через встроенный в ERP стандартный модуль, который прилично доработан. Автоматический обмен реализован через веб-сервис в режиме real-time. Сайт полностью адаптивен для работы на смартфонах, сейчас это 20% пользователей.

Личный кабинет клиента - главная страница

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

Личный опыт: Удобный пользовательский интерфейс на первом месте Краткий (слева) и полный вид (справа) карточек договоров, изменение вида в 1 клик

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

Краткое уведомление о проблеме по заказу прямо в списке (не достаточно денег)

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

Полное уведомление о проблеме по заказу в центре нотификации (сколько не хватает денег)Пример других страниц сайта личного кабинета Примеры страниц мобильной версии сайта личного кабинета

Быстрое получение счета на оплату по email

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

Клиент запрашивает счет в личном кабинете и получает в почте через 3-5 секунд (именно столько времени требуется для автоматического формирования счета в ERP и его отправки роботом из ERP на email контактного лица).

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

Счет на оплату автоматически сгенерирован в ERP и сразу отправляются на email контактного лица в формате PDF (на фирменном бланке и с факсимиле).

Счет на оплату, отправленный роботом из ERP на email контактного лица по запросу из личного кабинета

Чат-боты в Telegram для уведомлений и внутренних согласований

Для уведомлений клиентов о статусе мы используем Email-робота и SMS-робота (подробнее в первой части), чат-бот в Telegram.

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

Пример уведомлений клиентов в чат-боте Telegram

Чат-боты в Telegram для менеджеров и руководителей продаж

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

Бэк-офис регистрирует новые интересы в CRM-системе (подробнее в первой части), а робот в ERP мгновенно уведомляет менеджеров в чат-боте Telegram.

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

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

Менеджер по продажам или менеджер бэк-офиса может запросить согласование технического кредита в ERP по различным параметрам:

• С лимитом по сумме

• С лимитом по тоннажу

• С лимитом по количеству машин

• С лимитом по количеству вагонов

• На увеличение ранее согласованного тех.кредита (по сумме, тоннажу, машинам или вагонам)

Примеры различных тех.кредитов в ERP для согласования с руководителем

Руководители двух коммерческих дирекций получают мгновенные уведомления в чат-боте Telegram на согласование тех.кредитов.

Уведомление руководителю в чат-бот Telegram на согласование тех.кредита

Руководитель может инициировать согласование тех.кредита для клиента командой НАЧАТЬ СОГЛАСОВАНИЕ, ознакомившись с информацией - СОГЛАСОВАТЬ или НЕ СОГЛАСОВАТЬ.

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

Уведомление менеджера в чат-боте Telegram о результате согласования тех.кредита руководителем

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

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

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

Тизер для будущей публикации о новой системе для кабины автопогрузчика

Спасибо, что дочитали до конца!

Где-то на просторах мультивселенной

Представьте на минуту, что вы капитан Сиракузии, которая в 239 году до н. э. приближается к острову Фарос, что близ города Александрии. Вследствие узости прохода, войти в гавань Александрии непростая задача, в особенности, для такого корабля, как ваш. Вы слышали, что за последний год навигация около острова улучшилась, так как был завершен Фаросский маяк, уникальное сооружение, заложенное еще при Птолемее I.

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

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

Проблема #1: external_id курильщика

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

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

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

Проблема #2: нет разделения моделей для запросов и ответов

Иногда в документации к API описываются модели, которые используются и в запросах к серверу, и в ответах я называю такие модели Jack of all trades (мастер на все руки). Ничего страшного в этом вроде нет, ровно до тех пор, пока у нас не появляются объекты вроде{ foo:value1, bar:value2 }, где поле foo заполняется в моделях запроса, а bar - в ответах сервера. Но это уже выясняется эмпирически в процессе интеграции.

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

Проблема #3: избыточная защита в неожиданных местах

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

Хорошая практика - убедиться, что получатель колбека действительно его получил - обычно достаточно проверить код ответа: 200 порядок, у нас в клубе джентльменам принято верить на слово. Если хочется подстраховаться, то можно договориться, что получатель, например, будет передаватьв ответе идентификатор колбека. Так по крайней мере мы будем уверены, что объект получен, и мы не стучимся в абстрактный эндпоинт в вакууме, возвращающий на любой запрос 200.

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

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

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

А вы часто встречаете реализацию защиты от MITM-атаки при обработке коллбека?

Проблема #4: изменение типа в зависимости от параметров

{transaction: {id:1}}

{transaction: [{id:1}]}

Как вам метод, который в зависимости от параметра в запросе будет возвращать в одном из полей ответа либо объект, либо массив, содержащий в себе один элемент?

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

Особенно неприятно то, что, при работе с JSON, например, через библиотеку Newtonsoft Json.NET вы будете получать высокоуровневую ошибку десериализации поля, а дальше долго и вдумчиво всматриваться в два одинаковых объекта, пока глаз не заметит пресловутую пару квадратных скобок

Проблема #5: делегированная безопасность

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

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

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

Заключение: как всё исправить

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

Поэтому возникает вопрос, а всегда ли мы при создании API думаем о его конечных пользователях? Чтобы сделать интерфейс по-настоящему удобным, стоит учитывать ряд моментов:

• Внутренняя кухня приложения не должна влиять на интеграцию. Обеспечение уникальности в течение интервала ~N явно как-то связано с ненужными внешнему пользователю особенностями системы. Функции external_id должны быть одинаковыми на протяжение всего времени жизни сущности в системе.

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

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

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

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

А какие трудности при работе над интеграционными проектами встречались вам? Делитесь описанием и своими решениями/советами в комментариях сделаем материал полезнее.

Практический кейс о том, как разработать свой сценарий интеграции.

Появившиеся в 2006 году сервисы Google по работе с текстовыми документами (Google Docs) и таблицами (Google Sheets), дополненные 6 лет спустя возможностями работы с виртуальным диском (Google Drive), завоевали широкую любовь пользователей, лишив компанию Microsoft сложившейся десятилетиями монополии на работу с офисным программным обеспечением.

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

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

В базовом функционале CRM-систем интеграция с сервисами Google представлена лишь в Битрикс24 и предполагает создание пустого документа на базе диска с переходом в режим редактирования при последующем клике на него.

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

Для того, чтобы выполнить какое-то действие на Google диске своего аккаунта есть два подхода: вызвать соответствующий REST API метод или запустить написанный Google Script. Как показал наш опыт, REST API библиотека Google пока имеет гораздо более бедный набор возможностей по отношению к скриптам, например, с помощью метода create можно создать исключительно пустой документ без наполнения. Поэтому, универсальным является сейчас комбинированный подход, заключающийся в написании исполняемого скрипта, который будет вызываться извне с помощью API с определенным набором параметров.

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

Шаг 1. Создание скрипта

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

Сам script добавляется на диске точно также как мы добавляем обычный файл на него.

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

Шаг 2. Привязка скрипта к проекту Google Cloud Platform

После того как скрипт написан рекомендуем прогнать его, нажав кнопку Выполнить в редакторе. Далее вам необходимо создать проект на Google Cloud Platform. Наиболее простым вариантом для этого является нажатие кнопки Enable Google Script API по ссылке:https://developers.google.com/apps-script/api/quickstart/php.

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

Шаг 3. Публикация скрипта

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

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

Шаг 4. Написание PHP-обработчика

Для работы с API Google существует готовая библиотека, которую вы подключаете к своему проекту командой: composer require google/apiclient:^2.0

В файле с подключенной библиотекой вызываете функцию для подключения токена авторизации:

function getClient(){    $client = new Google_Client();    $client->setApplicationName('Google Apps Script API PHP Quickstart');    // перечисляем области действия токена через пробел    $client->setScopes("https://www.googleapis.com/auth/documents https://www.googleapis.com/auth/drive");    // файл credential.json, полученный от Google$client->setAuthConfig('credentials.json');    $client->setAccessType('offline');    $client->setPrompt('select_account consent');    // Формируемый файл token.json    $tokenPath = 'token.json';    if (file_exists($tokenPath)) {        $accessToken = json_decode(file_get_contents($tokenPath), true);        $client->setAccessToken($accessToken);    }    // Действие если токен просрочен    if ($client->isAccessTokenExpired()) {        if ($client->getRefreshToken()) {            $client->fetchAccessTokenWithRefreshToken($client->getRefreshToken());        } else {            $authUrl = $client->createAuthUrl();            printf("Open the following link in your browser:\n%s\n", $authUrl);            print 'Enter verification code: ';            $authCode = trim(fgets(STDIN));            $accessToken = $client->fetchAccessTokenWithAuthCode($authCode);            print_r($accessToken);            $client->setAccessToken($accessToken);                        if (array_key_exists('error', $accessToken)) {                throw new Exception(join(', ', $accessToken));            }        }        // Сохранение токена в файл        if (!file_exists(dirname($tokenPath))) {            mkdir(dirname($tokenPath), 0700, true);        }        file_put_contents($tokenPath, json_encode($client->getAccessToken()));    }    return $client;}

Файл с этой функцией должен быть изначально исполнен в командной строке ssh клиента php (имя файла).

При первом запуске на экране появится url, который вы открываете в своем браузере и дав необходимые разрешения копируете verification code из url ресурса приложения, который вы указали на шаге 1, вставляя его в командную строку. После этого система создает файл токена авторизации (token.json), сохраняя его в папке PHP-обработчика. Следует отметить,что данную операцию надо выполнить один раз.

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

// вызов ранее описанной функции для получения токена авторизации$client = getClient();$service = new Google_Service_Script($client);// код развернутого скрипта$scriptId = '***********************wKhTTdKL7ChremS5AkvzwlPJARnxqisW7TzDB ';$request = new Google_Service_Script_ExecutionRequest();// имя и параметры функции в рамках скрипта$request->setFunction('FillTemplate');$request->setParameters([$_REQUEST['customer'],$_REQUEST['link'],$_REQUEST['formsv'],$_REQUEST['socnet'],$_REQUEST['whatsi'],   $_REQUEST['ats'],$_REQUEST['pipeline'],$_REQUEST['outscope'],$_REQUEST['editor'],$_REQUEST['viewer']]);try {    // Make the API request.    $response = $service->scripts->run($scriptId, $request);    if ($response->getError()) {        // Обработчик ошибок        $error = $response->getError()['details'][0];        printf("Script error message: %s\n", $error['errorMessage']);        if (array_key_exists('scriptStackTraceElements', $error)) {            print "Script error stacktrace:\n";            foreach($error['scriptStackTraceElements'] as $trace) {                printf("\t%s: %d\n", $trace['function'], $trace['lineNumber']);            }        }    }     } catch (Exception $e) {    // Обработчик исключения    echo 'Caught exception: ', $e->getMessage(), "\n";}

Шаг 5. Вызов PHP-обработчика из CRM

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

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

• amoCRM;

• Битрикс24.

При этом, в Битрикс24 вебхук может быть встроен в бизнес-процесс, получая в качестве своих Get-параметров данные из сделки, переменных и констант бизнес-процесса.

Итогом работы данного вебхука стали добавляемые документы в соответствующую папку Google Drive:

Существенным ограничением запусков обработчиков через вебхуки является предельно допустимая длина URL, в которой будут передаваться Get-параметры. Напомним, что она составляет 4 кб (или 2048 символов).

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