На тази страница
Предложена синхронизация има двадесет кутии. Кутия седем копира статус в електронна таблица. Кутия осем преформатира таблицата за платформа за имейли. Кутия девет изпраща имейл на ръководител за одобрение на импорта. Планът пита кой агент трябва да изпълнява кутии седем до девет.
Първият въпрос е защо тези кутии съществуват. Примерът е илюстративен, не одит на реален екип.
Разговор за проектиране на процеси предлага четири категории работа: махнете стъпката, използвайте обикновен код, използвайте агент или оставете човешко решение. Полезното действие идва преди избора на модел. Премахването на стъпка може да премахне нуждата от целия механизъм около нея.
Започнете от видимия за клиента резултат
Назовете резултата, който процесът трябва да произведе. За връзка между магазин и система за имейли това може да е „клиент, който е купил, вече не получава напомняне за количка“. Резултатът предполага състояние, време и правило за спиране. Не предполага електронна таблица, пълен нощен експорт или поща на ръководител.
Илюстрацията на Tajo по-долу насочва прегледа към предложеното съпоставяне и границата преди активиране. Тя не реализира спиране на напомнянията за изоставена количка. За този резултат операторът първо трябва да определи сигнала за покупка и правилото за спиране. Още едно съпоставено поле не замества тези решения.
Прегледайте синхронизацията преди изпълнение
Синхронизирайте промените по клиентите с моята имейл платформа.
Синхронизация на клиенти
| Поле източник | Поле цел | Правило |
|---|---|---|
email | EMAIL | Директно |
first_name | FIRSTNAME | Директно |
last_name | LASTNAME | Директно |
Синтетичната предварителна проверка премина успешно
Съпоставени са 3 полета · Няма запис в целевата система
Илюстративен изглед, основан на инструментите на Tajo за съпоставяне. Синтетичната проверка и запазената чернова не активират синхронизация.
Проследете съществуващия път назад от резултата. За всяка стъпка попитайте какво ще се повреди, ако изчезне. Истинският контрол има отговор: съгласието ще бъде загубено, оспорено плащане ще бъде игнорирано или може да се изпрати неразрешено съобщение. Предаване по навик може да има само исторически отговор: старата система се е нуждаела от файл.
Категорията „премахнете“ не е разрешение да изтривате защити. Проверете предназначението на всяка стъпка, преди да я класифицирате.
- Необходим резултатрезултат за клиентаназад по пътя
- Преглед на стъпкитецел и контролмахнете излишното
- Запазена работас отговорник и проверима
Прегледът посочва какво трябва да се достави и зависимостите, които действително го защитават. Ако електронна таблица носи бизнес преценка, липсваща другаде, преценката трябва да остане, дори файлът да изчезне.
| Вид стъпка | Въпрос | Пример в илюстративен процес за колички |
|---|---|---|
| Премахване | Пази ли или произвежда ли необходимия резултат? | Дублиран експорт, който никой не чете |
| Обикновен код | Точно и стабилно ли е правилото? | Спира напомняне, когато има проверена покупка |
| Преценка на модел | Стъпката изисква ли ограничено тълкуване? | Насочва заявка в свободен текст към правилния екип |
| Човек или одобрена политика | Изборът дава ли правомощие или носи значими последствия? | Одобрява достъп до клиентски данни |
Таблицата е инструмент за проектиране. Не описва как са били класифицирани действителните стъпки на компания.
Поставете точните правила в код
API извикване, проверка на поле, сравнение на времеви отметки или проверка на право не стават по-добри, когато модел импровизира. Кодът може да изрази неизменно условие, да се изпълни по един и същи начин два пъти и да произведе проверим провал. Използвайте го, когато правилото може да се каже точно.
При примера с количката събитие за покупка може да закъснее или да дойде два пъти. Програмата трябва да идентифицира поръчката, да сравни текущото състояние и да откаже напомняне, когато покупката е известна. Ако системата не може да установи дали има покупка, се нуждае от състояние „неизвестно“. Модел не може сам да си даде право да предполага, че клиентът не е купил.
Някои задачи не се побират в точни правила. Заявка към поддръжката може да гласи: „Купих вчера, но на разписката е старият ми адрес“. Насочването ѝ може да използва ограничена смислова преценка. Изходът трябва да е известен екип или „неясно“, не отворена инструкция за промяна на поръчката. Дръжте решението на модела отделно от кода, който налага достъп и записва състоянието.
Защо един агент може да скрие стъпките
„Един агент може да прочете процеса и да направи всичко.“ Демонстрацията може да го направи да изглежда по-просто. В реална работа някой все пак трябва да обясни защо агентът може да вижда запис, какви действия може да прави и как се връща лошо действие. Агент с широк обхват често скрива същите стъпки в подкана и маха етикетите, които са ги правели проверими.
Второ възражение е, че прегледът в четири категории сам струва време. Така е. Пазете го кратък. Изберете един клиентски резултат, избройте нужните стъпки и попитайте какво добавя всяка. Упражнението има стойност само ако намалява работата или изяснява отговорността. Сложен одит на всяка съседна система става още една кутия.
Тествайте класификацията с нормален и неуспешен случай. Ако премахната стъпка тайно е била контрол, тестът трябва да го разкрие. Ако преценка на модел не може да се оцени с примери, стеснете я или върнете решението на човек. Ако кодът трябва да се променя при всяко клиентско изключение, отделете стабилния механизъм от местното бизнес правило.
Прегледът има нужда и от условие за спиране. Екип може да разлага всяка задача, докато класификацията струва повече от спестената работа. Спрете, когато всяка запазена стъпка има отговорник, задействащо събитие и проверима причина да съществува. Запишете единствената неизвестност, която би променила дизайна, после я тествайте в най-малката реална част. За синхронизация това може да е дали събитието за покупка пристига достатъчно рано, за да спре планирано напомняне. Ръководството за интеграции дава по-широк ред за планиране; четирите категории пазят този ред от запазване на ненужни стъпки. Прегледайте класификацията отново, когато процесът или правата му се променят.
Най-евтината стъпка е тази, която резултатът никога не е изисквал.
Често Задавани Въпроси
Какво трябва да се премахне преди автоматизацията?
Кандидат е стъпка, която съществува само заради предаване, което може да се премахне, дублиран запис или неизползван отчет. Преди премахване проверете кои хора и системи използват резултата ѝ и какви контроли зависят от нея.
Кога стъпка се нуждае от модел?
Използвайте модел за тясна смислова преценка, която не може да се изрази като стабилно точно правило, с наблюдавани входове, типизирани изходи и път за несигурност.
Кои решения трябва да останат при човек?
Оставете изборите, които изискват съгласие, дават права или носят последствия извън разрешения обхват на системата, при отговорен човек или изрично одобрена политика.