Ландшафт Steve Trucking

🌐 Також доступно 28 мовами

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Зображення згенеровано ШІ

Перекладено ШІ. Спільнота ще не перевірила. Читати англійською

Модуль 6 з 6 розділу Розуміння корпоративних даних, розділ 4 курсу Data Architect. Кожен модуль самостійний. Попередній: Стратегія org — це рішення рівня ландшафту · Наступний: наступний розділ, Якість даних і врядування

Питання, на яке відповідає цей модуль: Що каже нам справжній ландшафт, перш ніж ми щось проєктуємо?

Цей розділ увесь час відводив камеру: Salesforce як одна система з багатьох, види даних, системи навколо Salesforce, як малювати ландшафт і стратегія org. Тепер зберімо все разом на Steve Trucking. Але ми поки нічого не виправлятимемо. Це і є дисципліна: намалюйте те, що існує, пройдіть кожною стрілкою і подивіться, що каже ландшафт.

Почніть із того, що ми знаємо

Steve Trucking працює з однією org Salesforce у США. Service Cloud обробляє звернення від отримувачів і роздрібних партнерів; Field Service веде візити, бригади й мобільний застосунок; Experience Cloud дає роздрібним партнерам портал, який сьогодні використовують лише для претензій і звітів; Sales Cloud відстежує договори з партнерами й заявки на нові DC. Тож Salesforce іде посередині.

Ліворуч люди: 45 координаторів диспетчеризації, що працюють у DC роздрібних партнерів, близько 700 членів бригад на 330 вантажівках, 60 агентів служби підтримки клієнтів, 40 працівників операцій, фінансів і продажів і близько 300 користувачів роздрібних партнерів. Це вже щось каже: це не відомча CRM. Це операційна платформа для більшої частини бізнесу. Але це досі один прямокутник. Подивімося, що його оточує.

Click to enlarge

Steve Trucking сьогодні, до належного впровадження. Кожен маніфест потрапляє в RouteDesk; координатори вручну переносять маршрути в Salesforce, а завершені зупинки — назад; у FleetLink бракує з’єднання.

Позначте, що не так

Це поточний стан, до належного впровадження, і я так і пишу на малюнку. Тоді я розкриваю палітру. На ландшафті готової системи я не використовую червоний; на поточному стані — використовую. Червоне позначає поганий або неналежний процес, штрихове — те, що робиться вручну, а червоні точки — з’єднання, якого бракує. Пропущена стрілка теж дещо каже. Ніщо з цього не прикраса: кожна червона лінія — це вимога, яка чекає, щоб її записали.

Три партнери, три інтеграції

Три роздрібні партнери надсилають маніфести трьома різними способами, тож малюйте кожного окремо.

Keystone щодня по обіді кладе CSV-маніфест на SFTP-сервер для доставки через два дні і хоче щоночі отримувати файл статусів назад. Дві стрілки: маніфест усередину файлом, ініційований Keystone, і статус назовні файлом, ініційований RouteDesk. Асинхронно, із широким часовим вікном.

Redrock надсилає маніфести через REST API і чекає оновлень статусу через webhook у міру того, як вони відбуваються. Дві стрілки, два механізми: Redrock звертається всередину з маніфестами через API, а RouteDesk звертається назовні зі статусом через webhook. Майже в реальному часі.

Brightwave надсилає EDI-файли через мережу третьої сторони і чекає назад EDI-повідомлень статусу. Інший формат, інший механізм.

Ті самі бізнес-поняття (маніфест, доставка, статус), три зовсім різні інтеграції. Не спрощуйте малюнок, бо хочеться, щоб вони були однаковими. Вони не однакові. Це поточний стан.

Потім пройдіть ними. Keystone: як автентифікується SFTP-з’єднання, куди потрапляє файл, що його забирає, як ми знаємо, що оброблено весь файл, що стається з поганим рядком і як Keystone дізнається про зміну раніше за сьогоднішній нічний файл? Redrock: як автентифікується API, що стається, коли падає будь-яка сторона, що вважається успішним webhook, що, як той самий статус прийде двічі? Brightwave: хто веде EDI-мережу, де відбувається трансляція, які підтвердження повертаються? Ми нічого не перепроєктовуємо. Ми виявляємо запитання. Це робота ландшафту.

RouteDesk досі тут

RouteDesk — застарілий настільний інструмент диспетчеризації й маршрутизації, яким координатори в кожному DC перетворюють маніфести на маршрути. Він містить вісім років історії доставок, і його заплановано вивести з ужитку. Однаково намалюйте його. Поширена помилка — пропустити систему, «від якої ми позбуваємося». Коли? Скажімо, відповідь — за вісімнадцять місяців. Тоді щонайменше вісімнадцять місяців вона частина архітектури, а її вісім років історії, близько п’яти мільйонів доставок, не зникають разом із застосунком. І подивіться, що виявляє ландшафт: RouteDesk і Salesforce не з’єднані. Бригади відпрацьовують свої зупинки в застосунку Field Service від Salesforce, але маршрути будують у RouteDesk, тож координатори щовечора вручну переносять їх у Salesforce, а потім переносять завершені зупинки назад у RouteDesk, щоб він міг надсилати статус партнерам. Близько 3300 зупинок на день, двічі, вручну. На малюнку це штрихове й червоне. Це також каже вам, що webhook Redrock «у міру того, як вони відбуваються» насправді не такий. Чим RouteDesk володіє сьогодні? Що від нього залежить? Яка історія має його пережити і де: у Salesforce, сховищі даних, архіві? Ми ще не відповідаємо. Ландшафт щойно виявив запитання.

FleetLink — острів

FleetLink, телематична платформа, отримує GPS від кожної вантажівки: близько 200 000 показань на день, кожна вантажівка, кожна хвилина роботи. І вона ні з чим не з’єднана. Координатори дивляться на неї на окремому екрані. Тож малюйте FleetLink без стрілок. Жодної магічної інтеграційної лінії лише тому, що нам здається, ніби вона має бути.

Потім порахуйте нулі: 200 000 на день — це понад 70 мільйонів на рік. Це не «у нас є дані GPS». Це потокове джерело з багатьма нулями, що лежить поза досвідом Salesforce. Чи потрібні Salesforce 70 мільйонів показань на рік? Мабуть, не всі. Це проєктне запитання на потім.

У фінансів своя правда

Фінансова ERP виставляє кожному роздрібному партнерові рахунки за доставку, встановлення й вивезення старого і виплачує премії бригадам. А кількість доставок потрапляє туди через щомісячну таблицю. Намалюйте таблицю. Не замінюйте її охайною API-стрілкою, бо ми архітектори й знаємо краще; вона частина поточної архітектури. А коли вона намальована, приходять запитання: хто її робить, з якої системи, хто перевіряє, що, як доставка зміниться після надсилання, і чиє число перемагає? До відповідей прив’язані гроші.

Snowflake отримує щотижневий експорт

Snowflake містить аналітику операцій і фінансів, яку живить щотижневий експорт. Сам Snowflake цього не робить; це робить щось посередині: запланована задача експорту, що працює поза Salesforce, забирає дані через Bulk API і завантажує їх у Snowflake. Аналітика живе там, де живуть дані, і Snowflake уже є аналітичним домом. Але таймінг теж дещо каже. «Що сталося минулого місяця?» Щотижневий потік годиться. «Де ця доставка просто зараз?» Зі Snowflake я б не починав. Те саме підприємство, інше навантаження, інша свіжість, інша відповідь.

Ідентичність доходить до всіх по-різному

Корпоративний постачальник ідентичності йде над Salesforce. Офісний персонал користується single sign-on. Але координатори й бригади входять з обліковими даними Salesforce. Тож одна лінія довіри від IdP до Salesforce сховала б пів історії. Справжнє запитання — які користувачі входять яким шляхом, і цьому місце на ландшафті.

У досвіді отримувача є прогалина

Провайдер SMS і пошти надсилає отримувачам узагальнене повідомлення «ваша доставка завтра» з RouteDesk. Посилання для відстеження немає. Тим часом звернень близько 180 000 на рік, і близько 60% із них — «де моя доставка?»: приблизно 108 000 звернень на рік з тим самим запитанням. Тепер покладіть це поруч із FleetLink. Компанія знає, де її вантажівки. Її отримувачі продовжують дзвонити й питати. А система, що знає, не з’єднана з тією, що відповідає. Мені поки не треба проєктувати рішення. Ландшафт уже розповідає історію.

Покладіть нулі в інвентаризацію

Тепер порахуйте, що рухається. Як і в модулі 4, нулі не йдуть на стрілки; вони йдуть в інвентаризацію за малюнком, де вони визначатимуть механізми, коли ми проєктуватимемо. Близько мільйона доставок на рік, близько 3300 на день, із зростанням на 30% на рік; у середньому близько 1,6 позиції на кожну; близько восьми оновлень статусу на кожну, тож сьогодні це вісім мільйонів оновлень статусу на рік; від чотирьох до п’яти мільйонів фото на рік, зараз на власних телефонах бригад; близько 200 000 показань GPS на день; близько 180 000 звернень на рік. Стрілка з підписом «статус доставки» — не випадкове повідомлення. Прямокутники кажуть вам, що існує. Стрілки кажуть, що рухається. Нулі кажуть, чи переживуть ваші припущення зустріч із реальністю.

Click to enlarge

Інвентаризація за ландшафтом Steve Trucking: обсяг поруч із механізмом, який він визначатиме.

Цільової архітектури ще немає, а я вже бачу, де живуть важливі дані, що це за вид, як швидко вони рухаються і як системи ними обмінюються.

За межами іспиту: що змінює ШІ. Припустімо, Steve Trucking будує агента, щоб відповідати на запитання отримувача «де моя доставка?». Яку систему він має питати? Salesforce знає про візит, FleetLink знає, де вантажівка, маніфест партнера визначив доставку. Поточний ландшафт — це карта агента, і перш ніж агент зможе безпечно відповідати, архітектор має знати, яка система авторитетна для кожного факту і наскільки він актуальний. Спрямуйте агента не на те джерело — і застарілі дані стануть упевненою відповіддю.

Читайте біль, але поки не виправляйте

Відступіть. Три партнери, три стилі інтеграції. Застарілий інструмент диспетчеризації з вісьмома роками історії, і координатори, що вручну переносять 3300 зупинок на день у Salesforce і назад. Телематична платформа з 200 000 показань на день, не з’єднана. Фінанси, що рахують доставки зі щомісячної таблиці. Аналітика, що відстає на тиждень. Single sign-on для одних користувачів, для інших — ні. Немає посилання для відстеження, і 108 000 звернень на рік питають, де доставка. Усе зростає на 30% на рік.

Це чимало архітектури з одного малюнка. Спокуса — почати виправляти. Не треба. Поки що ні. Я хочу, щоб вам було комфортно лишити діаграму поточного стану потворною, бо іноді поточний стан потворний. Суть не в тому, щоб когось вразити чистим малюнком; суть у спільному розумінні реальності. Перепроєктовуйте під час документування — і ви втратите базову лінію. Пізніше я хочу сказати: ось що існувало, ось яку проблему ми розв’язали, ось що змінили і чому. Розділ 6 починає ухвалювати рішення про власність та ідентичність, а Контрольна точка 1 зводить Частину 1 разом. Курс Integration Architect проєктує потоки партнерів углиб.

Що тут вирішує архітектор

На цьому етапі архітектор не вирішує щодо цільової архітектури. Рішення — чи поточний стан зрозумілий достатньо добре, щоб її спроєктувати:

• Які системи, групи користувачів, сховища даних і зовнішні партнери справді існують сьогодні.
• Які дані перетинають кожну важливу межу, в якому напрямку, як часто і яким механізмом.
• Де зараз живуть операційні, аналітичні, потокові, історичні й неструктуровані дані.
• Які потоки несуть найбільший обсяг і заслуговують на ранню увагу.
• Які прогалини, ручні кроки, роз’єднані системи, неясна авторитетність і неузгоджені шаблони стають явними проєктними запитаннями.

Цей розділ почався з однієї ідеї: малюйте ландшафт, перш ніж проєктувати org. Якби я почав із моделі даних Steve Trucking, я міг би годинами займатися об’єктами й зв’язками, поки FleetLink стояв би осторонь із 200 000 показань на день, RouteDesk тримав би вісім років історії, три партнери говорили б трьома мовами, фінанси користувалися б таблицею, а сто тисяч звернень на рік питали б, де доставка. Це не запитання об’єктної моделі. Це запитання корпоративних даних. Намалюйте потворні інтеграції, таблицю, систему, яку нібито виводять з ужитку. Запишіть нулі. Пройдіть кожною стрілкою. Тоді ви готові це змінювати.

Додаткові матеріали

• Бриф Steve Trucking, розділи 2–4, і його діаграма ландшафту.