Я рефакторю компании

Kate

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

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

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

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

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

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

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


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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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


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

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

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


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

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

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

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

 
Сверху