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

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

Мы превращаем людей в скрипты, а потом заменяем их, если получается.

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

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

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

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

Что такое «Построение систем управления бизнес-процессами»

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

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

Даже если все в такой системе работают идеально (что случается редко), то всё равно возникают классические проблемы распространения информации. Во-первых, очень многое покрывается интуитивными догадками и понятийными договорённостями между участниками процесса. Во-вторых, некоторые задачи могут просто не принадлежать никому. Где-то вместо пересечения ответственности возникает дыра, и там начинаются проблемы. Но самое главное — новые процессы делаются с огромным трудом, потому что требуют перестроения всех уже слегка окостеневших цепочек договорённостей. Думаю, что вы такое видели в любой большой компании. Всё это со временем начинает очень сказываться на эффективности бизнеса.

Вот как только эти проблемы становятся настолько болезненными, что за их решения готовы платить, появляется бизнес-аналитик.

Как это выглядит на практике

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

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

Проблемы очевидны.

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

Три стадии работы с процессом

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

• Скинуть на одного ответственного.
• Поставить бизнес-процесс.
• Автоматизировать процесс.

То есть идеальное состояние — есть некая ИТ-система, которая автоматически всё делает, а там, где нужно человеческое решение, дёргает по API нужного сотрудника и просит принять решение в заданных условиях в заданный срок. Естественно, идти до такого долго и дорого. Поддерживать ещё дороже, а вносить изменения — тот ещё квест.

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

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

Что такое процесс

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

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

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

Обычно назначение одного ответственного означает построение какой-то дополнительной системы контроля, повышение требований к квалификации (чтобы она соответствовала задаче) и невозможность масштабирования.

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

То есть заменить суперсолдата Василия на много маленьких отдельных действий разных людей из разных команд.

Построение сквозного процесса между подразделениями

Чаще всего первое, что делает бизнес-архитектор или бизнес-аналитик в такой ситуации, — это идёт ко всем командам и начинает выискивать и лечить проблемы. Повторюсь: обычно проблемы такого характера лежат на стыке команд, потому что «эти нехорошие люди там не понимают, что…». Собственно, аналитик собирает в одной комнате отважных супергероев и «этих нехороших людей там» и просит рассказать, чего они друг от друга вообще ждут.

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

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

Если в процесс не встревать, то через некоторое время возможен один из двух результатов:

• Массовая драка.
• Договорённость, в которой три подразделения стремятся к решению, в котором ответственности и работы меньше всего.

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

Метрика означает возможность её оптимизации.

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

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

А Василий становится владельцем процесса, то есть тем, кто отвечает за его результат. В идеале Василий и должен был обладать навыками бизнес-архитектора и сам выстраивать свои процессы, но благо, что так бывает крайне редко. Почему благо? Потому что это даёт мне работу! Да и владелец процесса часто занят достижением результата, ему не до изменений.

Результат работы бизнес-архитектора — формализованный процесс, который надо постепенно внедрить и следить за его исполнением, а потом оптимизировать по возможности.

Пример, в котором архитектора нет

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

Чаще сопротивление принимает не такие радикальные формы. Просто, например, отдел контроля качества и производство могут договориться, что выпускают что-то в компромиссном виде, если очень торопятся. У меня была ситуация, когда QA оценивал фичу в продукте не по уровню качества для клиента, а по времени разработки: если она шла тяжело, то клиент страдал, потому что QA выпускал недоделанное в прод. Клиент же может получить результат, стоя на одной ноге и прыгая? Может. Значит, порядок. А за клиентский результат никто не отвечает. Результатом очень часто оказывался крайне кривой интерфейс при отличном бэке. И разрабы — герои, и продакт — герой, и QA всё сделали круто, только клиенты не рады. Потому что всем удобно, а про клиента забыли. Нужна метрика про него тоже.

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

Почему нужны процессы

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

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

Дальше — уже централизованное управление изменениями. Когда что-то меняется во внешнем мире, это может отразиться на процессе, и архитектор делает ещё раз ту же самую работу (только он уже знает, что, почему и как работает) и выполняет цикл быстрее. Дальше это имплементируется, чтобы ничего не поломалось.

Что может поломаться?

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

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

ОК, каковы тогда требования к архитектору?

Первое и самое главное — нужно понимать системный анализ. Это как про ИТ-системы: сущность, связь, цикл управления, обратная связь. Важно понимать модель данных процесса. Любой процесс — это изменение объекта управления путём последовательных действий. Часто эти изменения происходят в информационных системах либо могут быть легко представлены как информационные сущности. Любой бизнес-процесс сводится к какой-то модели данных вроде передачи информации по шине, API-сервисной архитектуры и так далее. Понимая компанию таким путём, архитектор сможет выставлять правильные бизнес-требования к системам автоматизации и к людям. Глубина понимания этой модели данных означает правильность требований техзаданий на входе.

Чаще всего архитектор должен знать все основные процессы и информационные системы компании как раз для того, чтобы, внедряя одно, не поломать другое. Например, ему не нужно знать, как в ИТ-инфраструктуре (это «чёрный ящик» с девопсами) реализована та или иная функция, но очень важно знать, зачем она и какую часть деятельности поддерживает. А также как работают бухучёт, CRM и прочие основные сущности.

В итоге архитектор знает всё, но неглубоко.

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