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



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

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

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

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

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

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

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


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


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

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

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

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

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


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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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


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

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

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


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

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

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

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




Комментарии (13):

  1. akomiagin
    /#23965905 / +1

    Очень актуальная тема. Спасибо за интересный обзор

  2. ruomserg
    /#23966665 / +9

    Идея о том, что можно поставить систему KPI, а люди под нее подстроятся и это автоматически обеспечит достижение целей бизнеса — является изначально вредной. Идея платить за достижение KPI — вредительской, если только речь не идет об элементарной физической деятельности типа «копать отсюда и до обеда!».

    Практика показывает, что для изменения (или создания) живых бизнес-процессов должно сойтись много звезд на небе — как минимум некотрое количество образованных, и одновременно неравнодушных людей, плюс внешний фактор который заставляет искать изменений. И нет, процесс нельзя принести с улицы, вычитать в книжке — и внедрить как прокрустово ложе. То есть можно — но что-то в фирме при этом отвалится. Процессы надо вырастить. Потому что процессы и стандарты должны всеми руководителями пониматься именно как набор best-practice, к которому прилагается старое авиационное правило: «выполняй или объясняй».

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

    • ILBogoslovskiy
      /#23968139 / +2

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

      Наличие ограничения можно использовать для приоретизации изменений и оглядыватся на него при их внедрении, но нельзя совсем забывать про все остальное. При отличном процессе продаж, который идеально использует ограничение в виде объема склада и забытом процессе HR, однажды будет некому продавать. Ценность изменения вспомогательных процессов в уменьшении риска для основного. Это как про системного администратора, если он работает хорошо, то никто этого не видит, но стоит ему накосячить…

      • ruomserg
        /#23969685

        Хорошо найти еще одного человека, который читал Голдратта! :-)

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

        По содержательной части — мне запомнилась мысль с какого-то семинара: задача управленца не бегать и снимать ограничения в духе ранних книг Голдратта (хотя, в критичесекой ситуации и это тоже правильно!). Задача управленца — спроектировать и настройить систему (проект, производство, и т.д.) таким образом, чтобы ограничения возникали в заранее запрограммированных точках, где ими легко управлять. Например, в одном случае — выгоднее запрограммировать узкое место на производстве, и проводить селекцию входящих заявок, спуская в унитаз (wasting, прошу прощения) часть производительности маркетинга и продаж. В другом случае — рыночная ситуация может быть такой, что выгоднее недогружать производство, но гарантированно успевать обработать каждую входящую заявку. Теория Голдратта дает понимание, как настроить предприятие под любой из сценариев — но сама по себе не говорит, где «правильно» оставить ограничение (ибо, как мы понимаем, ограничения в системе будут всегда).

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

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

        • ILBogoslovskiy
          /#23971567 / +1

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

          Идея фиксации ограничения в одном месте описана в книге "Новая цель. Как объединить бережливое производство, шесть сигм и теорию ограничений", которая как видно из названия, делает попытку примерить непрерывное совершенствование lean и 6сигма c TOC.

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

          • RealGringo
            /#23972955

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

            Cоглашусь с комментариями @ruomsergвыше:

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

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

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

      • undersky
        /#23972935

        Да, как раз хотел сказать, что плюс-минус изложение книги «the goal» с адаптацией под современные реалии типа API :)

  3. iggr63
    /#23970239

    Про системного архитектора хорошо сказано "знает всё, но неглубоко".

  4. InOdinWeTrust
    /#23970291

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

    • ruomserg
      /#23971005 / +1

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

    • ILBogoslovskiy
      /#23971587 / +1

      А это уже отдельная тема про управление изменениями и цикл PDCA (PDSA), который еще в лохматые 40-е был впервые описан как раз для изменения процессов.

  5. g6uru
    /#23971435

    Процессы бесспорно важны, но более важным является управление человеческим фактором. Ивар Якобсон в последней своей книге раскрывает в целом, что послужило основным проигрышем RUP по сравнению с гибкими методологиями.

    > As strange as it may sound, the methods we employed in the early days did not pay much attention to the human factors. Everyone understood of course that software was developed by people, but very few books or papers were written about how to get people motivated and empowered in developing great software. The most successful method books were quite silent on the topic. It was basically assumed that in one way or the other this was the task of management.