Это четвёртая статья практической серии, продолжающей материал «Автоматизировать бардак нельзя навести порядок: где у ИТ должно быть право вето». В предыдущих статьях мы прошли от диагностики инициативы через ценность к ответственности; в предыдущей публикации разбирались, кто должен принимать критические решения и почему знание о риске ещё не даёт полномочий им управлять. Теперь следующий вопрос: что делать, когда система уже требует однозначного правила, а компания его ещё не выбрала?

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

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

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

Алгоритм не был случайным или заведомо нелепым. Он выглядел вполне логично и даже подтверждался историческими данными. Неприятность состояла в другом: никто в компании не принимал решения, что именно так должен работать процесс закупок. К моменту тестирования это решение уже существовало, только существовало оно не в регламенте и не в решении владельца процесса, а в коде.

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

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

Требование согласовано, ТЗ подписано, проект может двигаться. В песне Арчета про гвозди по ГОСТу как раз есть знакомая любому инженеру логика: если задание определено, не надо самовольно придумывать, как сделать «лучше», – надо хорошо выполнить заданное.

Этот принцип мне по-прежнему кажется здоровым.

Разработчик имеет полное право производить гвозди по ГОСТу. Но он не должен сам писать ГОСТ для закупок.

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

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

На одном из интервью аналитик спросил начальника отдела закупок, как это происходит сейчас. Ответ был примерно таким: «Я сам распределяю заявки. Смотрю и решаю, кому из категорийных менеджеров какую отдать». Для описания as is этого достаточно: заявка попадает к руководителю, он принимает решение, после чего появляется исполнитель. Для автоматизации описание слишком общее, потому что компьютеру недостаточно знать, что человек «смотрит и решает». Надо понять, на что он смотрит и какое правило связывает увиденное с выбором исполнителя.

Аналитик здесь сработал именно так, как от него и требуется. Он не принял строку ТЗ за готовое бизнес-правило и задал следующий вопрос:

Что делать, если в одной заявке есть позиции из разных категорий?

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

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

Мы пошли за ответом к участникам процесса и получили четыре разных варианта.

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

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

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

На этом месте особенно легко произнести любимую фразу ИТ: «Бизнес сам не знает, чего хочет». Только она почти ничего не объясняет. Все ответы были рациональны внутри задач конкретных подразделений. Производству важно обеспечить потребность целиком и к нужному сроку. Финансам – иметь однозначный и контролируемый маршрут. Складу – не разрушать связность заявки лишним размножением документов. Закупкам – сохранить возможность учитывать контекст.

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

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

Ни один из четверых не ошибался. Просто у каждого была своя зона ответственности, а общей — не было.

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

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

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

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

Некому было поставить точку.

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

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

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

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

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

Отсюда не следует правило «ИТ ничего не решает без бизнеса». Это парализовало бы любую разработку. Архитектор выбирает архитектурные решения, аналитик детализирует требования, разработчик каждый день принимает десятки решений реализации. Граница проходит там, где технический выбор начинает отвечать уже на вопрос о способе работы компании.

Если выбор отвечает на вопрос «как реализовать уже принятое правило?» – это зона ИТ. Если он определяет, «как теперь должна работать компания?» – требуется бизнес-решение.

Граница проходит не по сложности решения и не по тому, кто его придумал.

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

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

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

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

Когда начали разбираться, выяснилось, что значительная часть настоящей логики планирования вообще не попала в требования. Технологи годами пользовались ею, но не могли сразу превратить экспертное решение в формальное правило. На вопрос «почему вы сделали именно так?» поначалу получался ответ уровня «я смотрю на план и вижу».

Одинаковый ответ на интервью, два разных диагноза. Во втором случае ещё десять интервью ничего не дадут.

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

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

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

Для первого случая продолжается обследование. Для второго понадобится механизм принятия решения.

Алгоритм отработал верно. Мониторы от этого канцтоварами не стали.

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

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

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

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

Один из способов увидеть такую проблему – использовать BPMN не только как средство описания процесса, но и как детектор мест, где процесс на самом деле ещё не определён.

После создания заявки на схеме легко появляется вполне корректный шлюз: «Заявка содержит несколько категорий?» Если нет, система определяет категорийного менеджера и процесс идёт дальше. Если да, хочется нарисовать ещё одну развилку, например «Какая категория преобладает?», после чего направить заявку соответствующему менеджеру.

С точки зрения нотации схема безупречна: обе ветки закрыты, разработчику всё понятно.

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

Ромб в BPMN – это не всегда логика процесса. Иногда это замаскированное управленческое решение, которое никто не принял.

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

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

Иногда правильный результат моделирования выглядит как незакрытая развилка с честной пометкой: «Здесь процесс не определён. Требуется управленческое решение». Для проектной команды такая картинка психологически некомфортна: незаконченная схема похожа на недоработку, а закрытая – на прогресс. Именно поэтому вопрос лучше вынести из диаграммы в отдельный управляемый контур.

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

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

Реестр меняет характер разговора. Формулировка «уточнить алгоритм распределения многокатегорийных заявок» оставляет впечатление технического вопроса, который кто-нибудь должен доработать. Другая формулировка – «есть четыре технически реализуемые модели, они по-разному меняют процесс и ответственность, до реализации нужно определить одну из них и владельца решения» – показывает настоящий предмет выбора.

Особенно важны последствия. Если ИТ просто приносит бизнесу четыре строчки и говорит «выбирайте», оно тоже не выполняет свою часть работы. Владелец функционального направления может прекрасно знать закупки и при этом не видеть стоимости синхронизации документов, влияния на права доступа, архитектурных ограничений или объёма разработки. ИТ должно объяснить варианты, риски, ограничения, стоимость и при необходимости дать собственную рекомендацию.

ИТ делает выбор возможным и осознанным. Бизнес принимает решение о процессе. ИТ превращает его в работающую систему.

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

Не каждый открытый вопрос требует эскалации, и уж точно не каждый должен останавливать разработку. Иначе идея очень быстро деградирует до карикатуры, в которой ИТ требует директора на каждый if.

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

Формулировать остановку тоже важно правильно. «Бизнес не определился, работать не можем» почти гарантированно возвращает старый конфликт. Гораздо точнее звучит другая позиция: «Есть несколько реализуемых вариантов. Вот последствия и наша рекомендация. Выбор меняет бизнес-процесс, поэтому проектная команда не имеет полномочий принять его самостоятельно. До определения владельца и выбора варианта реализацию этой точки приостанавливаем».

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

В том проекте я эскалировал вопрос руководителю проекта заказчика. Сегодня я разделил бы две задачи. РП действительно должен обеспечить, чтобы критичный вопрос получил владельца, срок и решение. Но отсутствие владельца процесса нельзя компенсировать полномочиями руководителя проекта: тот способен организовать выбор, показать влияние задержки и вынести вопрос на нужный уровень, однако содержание правила закупочной функции не становится его зоной ответственности только потому, что проекту нужен ответ.

РП отвечает за то, чтобы решение состоялось. Это не делает его автором любого бизнес-решения.

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

1. Какое правило здесь должно действовать?

2. Оно уже существует или проектная команда только предлагает его?

3. Все участники понимают правило одинаково?

4. Что изменится при выборе разных вариантов?

5. Кто имеет полномочия установить окончательное правило?

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

Для нашего случая правильная формулировка звучала бы так: «Как компания должна обрабатывать потребность, содержащую несколько закупочных категорий?» После неё уже можно положить на стол варианты: разделение заявки, запрет смешанных категорий, одного ответственного или сохранение ручного распределения, – и показать последствия каждого.

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

Самый быстрый способ испортить инструмент – использовать его как оружие. ИТ собирает десяток открытых решений и приносит на проектный комитет доказательство того, что «проект стоит из-за бизнеса». Бизнес отвечает зеркально: «Вы специалисты, вам за это платят, вот сами и решайте». Обе стороны могут быть формально правы в отдельных аргументах, но реестр в такой конструкции перестаёт помогать принятию решений и превращается в журнал взаимных алиби.

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

Обратная крайность – приносить владельцу бизнеса пустой лист со словами «мы не знаем, скажите как надо». Владелец процесса не обязан проектировать информационную систему вместо аналитика. Его задача – выбрать модель работы между содержательно подготовленными вариантами. Точно так же опасен механизм молчаливого согласования: «если до пятницы не возразите, делаем вариант 2». Для технических мелочей такой способ бывает полезен, но отсутствие ответа не должно давать проектной команде полномочия изменить бизнес-правило.

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

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

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

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

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

Поэтому теперь, когда в требованиях появляется очередное «система должна автоматически определять…», я сначала задаю другой вопрос:

Правило, по которому система должна это определять, компания уже действительно приняла?

Если да, дальше начинается нормальная инженерная работа – можно производить гвозди по ГОСТу. Если нет, сначала нужен тот, кто имеет право этот ГОСТ написать.

Разработчик имеет полное право производить гвозди по ГОСТу. Но он не должен сам писать ГОСТ для закупок.

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

Но это уже следующая статья.

Проголосовали 5 пользователей. Воздержались 2 пользователя.