Обучение · Урок 4

Чем собирать: готовый пакет, no-code или своя разработка?

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

Чему вы научитесь в этом уроке

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

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

Цели урока

  • Различать три формы сборки: готовый пакет, no-code, своя разработка
  • Видеть, что решение об инструменте приходит после карты процесса
  • Оценивать кандидатов по семи критериям
  • Читать таблицу оценок и понимать, на какую форму она указывает
  • Спрашивать о владении данными и цене выхода в момент решения
  • Готовить пробную сборку до решения

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

Три формы сборки

Автоматизацию можно собрать в трёх формах. Все три бывают верными; какая верна, меняется с работой. Различение ниже — почва, на которой стоят дальнейшие критерии.

Готовый пакет

Система, сделанная под определённую работу и идущая так, как пришла. Настройка короткая, уход несёт поставщик. Взамен процесс подстраивается под продукт, а не продукт под процесс.

No-code

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

Своя разработка

Система, написанная под работу. Каков процесс, то и собирается; граница принадлежит работе, а не продукту. Взамен это форма с самой тяжёлой сборкой и уходом.

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

Разница не только в величине нагрузки, но и в её форме. В готовом пакете нагрузка ровная и предсказуемая, взамен от процесса ждут, что он уложится в продукт. На no-code сборка лёгкая, но с ростом числа потоков уход тихо копится. В своей разработке нагрузка собирается в начале и возвращается с каждой просьбой об изменении. Решая, держите в уме, что цена есть у всех трёх; разнится то, куда и когда она падает.

Когда принимается решение об инструменте?

Решение об инструменте приходит после записи процесса. В первом уроке звучала фраза «инструмент приходит последним»; этот урок — её прикладное соответствие. Сравнение инструментов без карты процесса превращается в сравнение списков возможностей.

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

Что стоит иметь до решения

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

Критерии 1-3: процесс, исключение, интеграция

Первые три из семи критериев смотрят на саму работу. Дайте каждому низкий, средний или высокий; при желании подойдёт и балл в диапазоне 0-100.

1 Устоялся ли процесс

Вышла ли карта, месяцами ли одинаковы шаги? Устоявшийся процесс подходит готовому пакету или своей разработке. Если процесс ещё меняется, no-code может нести изменение дёшево.

2 Число исключений

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

3 Потребность в интеграции

Скольких систем касается процесс? Работа, остающаяся в одной системе, может идти на готовом пакете. Если подключается несколько, вперёд выходят no-code или своя разработка.

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

Критерии 4-5: команда и уход

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

4 Умение команды

Кто будет менять поток? Если внутри есть человек, умеющий собирать потоки, no-code выдерживает. Если нет, каждое изменение просят снаружи и мелкие правки копятся.

5 Нагрузка ухода

Кто будет ухаживать после сборки? В готовом пакете уход у поставщика, на no-code и своей разработке — у вас. Решение, принятое без записи хозяина ухода, встречает вас на шестом месяце.

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

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

Критерии 6-7: владение данными и выход

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

6 Владение данными

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

7 Цена выхода

Что будет, если вы захотите уйти от этого инструмента? В каком виде выгружаются данные, переносимы ли потоки, встаёт ли работа во время перехода. Инструмент с неизвестным ответом — это зависимость.

Спросить о цене выхода в момент решения не значит планировать уход. Знать меру с самого начала делает будущее решение дешевле уже сегодня.

Как ведётся оценка?

Оцените семь критериев для каждого кандидата отдельно. Под кандидатом мы понимаем не три формы, а их осязаемые соответствия: имя рассматриваемого продукта, имя рассматриваемого no-code инструмента, запрошенное предложение на свою разработку.

Оценивая, спрашивайте не «хорош ли этот инструмент», а подходит ли он этой работе по этому критерию. Один и тот же инструмент бывает высоким на одной работе и низким на другой; таблица меряет не инструмент, а совпадение.

Порядок оценки

  • Выпишите кандидатов: имя продукта, no-code инструмент, предложение на свою разработку
  • По каждому критерию дайте низкий, средний или высокий и запишите обоснование одним предложением
  • Оставьте оценку пустой там, где обоснование не пишется; не заполняйте догадкой
  • Превратите пустые клетки в список вопросов поставщику
  • Когда вопросы получат ответ, дозаполните таблицу и лишь затем сравнивайте

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

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

Читать таблицу оценок

Когда таблица заполнена, обычно выходит один из трёх узоров. Узоры — подсказка, а не жёсткое правило; окончательное решение выходит из работы целиком.

Узор, указывающий на готовый пакет

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

Узор, указывающий на no-code

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

Узор, указывающий на свою разработку

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

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

Гибрид: пользоваться двумя формами вместе

Формы сборки не исключают друг друга. Распространённый порядок такой: записи и бухгалтерия стоят на готовом пакете, свойственные делу потоки собираются на no-code, и лишь единственная часть, не влезающая ни в один шаблон, пишется своей разработкой.

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

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

Что записать при сборке гибрида

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

Пробная сборка до решения

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

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

Что испытывается в пробной сборке

  • Собирается ли в этом инструменте один путь исключения из карты
  • Находят ли поля словаря соответствие в инструменте
  • Подключается ли на деле одна из систем, которые нужно связать
  • Может ли кто то из команды изменить поток
  • Выгружаются ли данные и в каком виде
  • Сообщает ли инструмент, когда что то идёт не так

План выхода пишется в начале

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

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

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

Что стоит в плане выхода

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

Разобранный пример: агентство недвижимости продолжает

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

От оценки к решению

Кандидаты: агентство выписывает трёх кандидатов. Готовый пакет для рынка недвижимости, общий no-code инструмент и предложение на свою разработку поверх существующей системы портфеля.

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

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

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

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

Чтение: готовый пакет остаётся низким по интеграции, владению данными и выходу. Своя разработка тяжела по нагрузке ухода. No-code выходит средним по трём критериям и высоким по четырём.

Проба: агентство собирает на no-code только шаг подтверждения получения и испытывает исключение с несовпавшим районом. Исключение собирается, система портфеля подключается, а консультант меняет поток сам.

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

Упражнение: сделать на этой неделе

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

Сделать на этой неделе

  • Выпишите трёх кандидатов: готовый пакет, no-code инструмент, предложение на свою разработку
  • Оцените семь критериев по каждому кандидату и к каждой оценке напишите обоснование одним предложением
  • Клетки без обоснования оставьте пустыми и перенесите в список вопросов
  • Задайте вопросы поставщикам и внесите ответы в таблицу
  • Одним предложением запишите, какой критерий для вас тяжелее
  • С вышедшим вперёд кандидатом соберите узкую пробу
  • Запишите пять пунктов плана выхода

Заполненная таблица становится входом пятого урока: первую автоматизацию вы соберёте выбранным инструментом.

Скачать таблицу сравнения инструментов (xlsx) · семь критериев, три кандидата и столбцы обоснований, вместе с разделами пробной сборки и плана выхода.

Частые ошибки

Сравнивать списки возможностей

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

Решать по показу

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

Пропускать умение команды

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

Откладывать владение данными

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

Оставлять цену выхода без вопроса

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

Грузить все процессы на один инструмент

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

Контрольный список

Прежде чем решение об инструменте будет принято, стоит уметь сказать «да» каждому пункту ниже.

Список решения об инструменте

  • Карта процесса на руках и свежая
  • Словарь полей записан, ключ склейки определён
  • Выписано не менее трёх кандидатов, и их формы различаются
  • Семь критериев оценены по каждому кандидату
  • У каждой оценки есть обоснование одним предложением
  • Пустые клетки ушли поставщику вопросами и получили ответ
  • О владении данными и цене выхода спросили письменно
  • С вышедшим вперёд кандидатом собрана узкая проба
  • В пробе испытан хотя бы один путь исключения
  • Записаны пять пунктов плана выхода

Словарь

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

Что дальше

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

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

Урок 5: Собрать первую автоматизацию

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

Урок 3: Правильный сбор клиентских данных

Словарь полей. Основа критерия владения данными.

Все уроки

Раздел обучения целиком и добавленные позже модули.

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

Запросить через WhatsApp

Частые вопросы

Какая форма сборки лучшая?
Такого ряда нет; мерило меняется с работой. Один и тот же инструмент бывает высоким на одной работе и низким на другой. Поэтому таблица меряет совпадение инструмента с работой, а не сам инструмент.
Хватает ли no-code инструментов растущему делу?
С ростом числа потоков и исключений растёт и нагрузка ухода. Если есть роль, способная вести потоки дальше, их может хватать долго; если нет, при накоплении просьб об изменении может появиться нужда перейти к другой форме.
Своя разработка только для крупных компаний?
Решает не величина дела, а своеобразие процесса. Процесс, полный исключений и не влезающий ни в один шаблон, может потребовать своей разработки и в небольшом деле.
Как спрашивать о владении данными?
Откройте словарь полей и спрашивайте поле за полем: выгружается ли это поле, в каком виде, за какой срок. Общий вопрос о том, наши ли данные, обычно получает общий ответ; вопрос на уровне поля приносит осязаемый.
Можно ли сменить инструмент после решения?
Можно, но цена зависит от того, был ли написан план выхода. Если вид данных, письменное определение потоков и способ ведения работы во время перехода записаны с самого начала, переход остаётся управляемым.