Plunet & Hubspot CRM

Цей посібник є нашим першим введенням в управління бізнес-процесами та архітектуру рішень. Тепер, коли ви знаєте як використовувати основні функції (birds, flights та apps), прийшов час вивчити навички, які допоможуть вам отримати максимальну користь від Blackbird!

Синхронізація даних між двома системами є типовим випадком використання Blackbird. Зазвичай вимоги мають форму: “Коли створюється новий x у системі y, синхронізувати його з системою z”. Сьогодні ми беремо Plunet і Hubspot як приклади систем для цього випадку, але, звісно, таку ж методологію можна застосувати до будь-яких інших двох систем.

Примітка: У цій статті, де ми згадуємо замовлення Plunet, його можна замінити на комерційну пропозицію Plunet або запит Plunet, також ви можете вибрати зв’язок з комерційними пропозиціями Hubspot.

1. Вимоги

Як скаже вам будь-який досвідчений розробник програмного забезпечення: отримати точні вимоги складно. Це тому, що у світі програмного забезпечення все можна точно визначити, але в людській мові ми схильні бути набагато “вільнішими” в описах того, чого хочемо досягти. Розглянемо реальний приклад вимоги користувача Blackbird:

“Ми хочемо синхронізувати замовлення Plunet з угодами Hubspot”

Ця вимога все ще далека від справжнього bird. Тому перший крок – отримати більше деталей. Припускаючи, що ми вже знаємо, що таке замовлення Plunet і угоди Hubspot, нам потрібно знайти відповідь на два найважливіші питання: Які дані потрібно синхронізувати і Коли ця синхронізація повинна відбуватися?

“Ми хочемо створювати угоду в Hubspot, коли в Plunet створюється замовлення. Сума угоди, назва, клієнт, контактна особа та менеджер проекту повинні бути синхронізовані”

Вже краще. Незалежно від того, чи впроваджуєте ви власні робочі процеси в Blackbird, чи працюєте з вимогами інших, вам потрібно вміти чітко формулювати Що має відбуватися Коли. Якщо цей бізнес-процес вже виконується “вручну” на періодичній основі, тоді може бути надзвичайно цінно (віртуально) посидіти поруч з цією людиною, коли вона виконує свої дії. Це може допомогти виявити приховані вимоги, а також дати вам стартову перевагу щодо кроків, які ми повинні зробити далі. У всіх випадках рекомендується, щоб вимогу можна було виконати хоча б вручну, навіть якщо вона сьогодні не є частиною жодного бізнес-процесу.

2. Відображення зв’язків

Тепер, коли ми краще розуміємо, що потрібно побудувати, нам необхідно отримати уявлення про те, як працюють ці системи. Що таке клієнт у Plunet? Що таке замовлення? І найголовніше: які еквівалентні представлення в Hubspot?

Почнемо з Plunet, але будемо стислими:

• Є кілька клієнтів.
• Кожен клієнт може мати кілька контактних осіб.
• Plunet має ‘внутрішні ресурси’, які представляють людей у вашій організації.
• Може бути кілька замовлень, кожне з яких представляє бізнес, узгоджений з клієнтом.
• Замовлення Plunet пов’язане з ‘внутрішнім ресурсом’ як менеджером проекту, клієнтом та контактною особою цього клієнта.

У Hubspot речі виглядають подібно, але з суттєвою відмінністю:

• Є кілька компаній
• Є кілька контактів
• Є кілька угод. Угода має ‘власника угоди’, який є користувачем Hubspot
• Між цими трьома сутностями існують зв’язки типу “багато-до-багатьох”. І Hubspot використовує ‘асоціації’ для відстеження цих зв’язків.

Ці структури достатньо схожі, щоб створити відображення між ними. Однак, у деяких випадках такої схожості не існує. У таких випадках доцільно дослідити, як люди відображали ці зв’язки у своїй організації.

Намалюємо карту семантичних зв’язків:

3. Впровадження зв’язків

Коли ми маємо справу з семантичними зв’язками, нам також потрібно зробити їх явними. Ми робимо це, щоб пізніше легко отримувати відповіді на питання виду “У мене є сутність x, як тепер отримати сутність y?”. Наприклад, ми знаємо, що в одній системі будуть дії для отримання певних зв’язків. Маючи замовлення Plunet, я легко можу отримати менеджера проекту. Маючи компанію Hubspot, я легко можу отримати контакти. Ці зв’язки та дії доступні одразу! Але як нам відобразити неявні зв’язки, які ми щойно визначили? Якщо у мене є замовлення Plunet, як отримати еквівалентну компанію в Hubspot?

Десь потрібно зберігати посилання на інші еквівалентні сутності. На щастя, і Plunet, і Hubspot дозволяють нам створювати та встановлювати користувацькі поля для кожної з цих сутностей.

Для Plunet ми створимо текстовий модуль і застосуємо його до Клієнтів, внутрішніх ресурсів та замовлень. Назва текстового модуля буде Hubspot ID, щоб ми могли зберігати ідентифікатори Hubspot еквівалентних сутностей. Для отримання додаткової інформації про текстові модулі див. документацію Plunet.

У Hubspot кожна сутність також може мати Користувацькі властивості (Settings -> Data Management -> Properties). Ми можемо створити нову властивість для кожної з наших відповідних сутностей. Для отримання додаткової інформації про користувацькі властивості див. документацію Hubspot

Ми створили інфраструктуру, необхідну для семантичного зв’язування сутностей у наших двох окремих системах, і ми готові перейти до наступного кроку!

4. Планування bird

Нагадаємо собі робочий процес, який ми намагаємося автоматизувати:

“Ми хочемо створювати угоду в Hubspot, коли в Plunet створюється замовлення. Сума угоди, назва, клієнт, контактна особа та менеджер проекту повинні бути синхронізовані”

Ми дійшли до найважливішого кроку, який ви робите перед створенням bird: розбиття проблеми на маленькі кроки. Стратегія, яку найчастіше можна застосувати для типових робочих процесів Blackbird, це які кроки людина зробила б для ручного виконання цього робочого процесу? - вже припускаючи наявність попередньої ‘інфраструктури’, яку ми створили. Якщо неможливо уявити, як робочий процес виконується вручну, то неможливо і навчити Blackbird робити це. Тому ручні кроки є основою нашої автоматизації.

Запишемо ручні кроки, які потрібно виконати, щоб синхронізувати замовлення Plunet з угодою Hubspot. Припускаємо, що замовлення вже створено.

1. Створити нову угоду в Hubspot і додати ціну, назву та дату з нашого замовлення Plunet.
2. Встановити користувацьку властивість ID замовлення Plunet в Hubspot з ID замовлення Plunet, яке ми створили
3. Після створення угоди отримати ID угоди з Hubspot і додати його до текстового модуля Hubspot ID в Plunet
4. Перейти до клієнта замовлення в Plunet і знайти його Hubspot ID з текстового модуля
5. Створити нову асоціацію між цим клієнтом Hubspot і угодою Hubspot
6. Перейти до контакту замовлення в Plunet і знайти його Hubspot ID
7. Створити нову асоціацію між контактом Hubspot і угодою Hubspot

Ви можете запитати, чому ми заповнюємо користувацькі властивості та текстові модулі, хоча вони не обов’язково потрібні для цього bird. Ми рекомендуємо це як гарну практику для створення цих асоціацій для майбутніх робочих процесів і сценаріїв.

Отже, схоже, що наш bird буде досить простим! Ми виконуємо близько 6 дій під час ручної синхронізації Plunet з Hubspot, тому можемо очікувати bird приблизно такого ж розміру.

5. Створення bird

Нарешті, ми готові створити bird! Якщо ви правильно спланували свої дії, то дії у вашому bird повинні в основному відповідати ручним крокам, які вам довелося б виконати.

Як бачите, пронумеровані дії відповідають крокам, які ми спланували вище!

Коли ви протестували цей потік сам по собі (ми рекомендуємо спочатку робити це з ручним тригером, просто взявши “жорстко закодоване” замовлення Plunet), ви можете почати думати про тригер: коли цей bird повинен “літати”?

Bird повинен спрацьовувати коли в Plunet створюється нове замовлення. Здається, що в Plunet є подія під назвою On order created. На жаль, це момент, коли нам знадобляться більш глибокі знання системи Plunet. А саме, ця подія спрацьовує не тоді, коли нове замовлення зберігається вперше, а в Plunet у момент натискання кнопки new order. Це надзвичайно непрактично, оскільки в цей момент все замовлення все ще буде порожнім.

Ми заохочуємо вас експериментувати з подіями (та діями) в ізольованих birds, просто щоб ознайомитися з їхньою поведінкою, перед тим як використовувати їх у більших сценаріях birds.

Не біда, є інша подія, яку ми можемо використати: On order status changed. Зазвичай менеджери проектів створюють нове замовлення і завершують фазу ініціалізації, змінюючи статус замовлення. Це повинен бути наш тригер!

Проблема, яка тепер виникає, полягає в тому, що ця зміна статусу може застосовуватися кілька разів. Уявіть, що менеджер проекту змінює на наш статус, спрацьовує bird, змінює статус туди-сюди і знову спрацьовує. Тепер у нас є дублікати угод Hubspot!

Найкращий спосіб обійти цю нову проблему, яку ми створили для себе, - це просто перевірити на початку, чи