Привет, Хабр! Я Максим Катаев, старший аналитик в отделе Mobile Core Тинькофф. Наш отдел разрабатывает общие компоненты для мобильных приложений: от авторизации до дизайн-системы. Они используются в приложениях экосистемы Тинькофф: Инвестициях, Бизнесе, Мобайле и прочих. 

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

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

Я постарался сделать акцент не на скучной теории, а на лайфхаках, которые можно применять на практике. Let's GOOOOO!

Как есть или как хочется

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

Бизнес-процессы бывают в двух состояниях: As is и To be. As is — текущее состояние, по которому живет компания сейчас. To be — желаемое состояние, по которому нужно, чтобы жила компания в будущем. Ну, вдруг вы не знали ????

Жизненный цикл бизнес-процесса, как правило, укладывается в пять этапов. Они закольцовываются и образуют цикл Business Process Management Lifecycle. Вот эти пять этапов, из которых состоит цикл:

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

   Еще здесь описывают оптимизируемый процесс в состоянии As is и подсвечивают проблемные моменты, которые требуют исправления. На первом этапе нужно собрать максимум контекста, с учетом которого будет выстраиваться разработка бизнес-процесса. 

2. Моделирование — Model. Этап, на котором нужно придумать, как исправить проблемы процесса As is и смоделировать, как процесс будет выглядеть в будущем — To be. 

3. Внедрение — Execute. Утвержденный процесс в нотации To be. Нужно избавиться от старого процесса и научить всех пользователей действовать по-новому.

4. Мониторинг — Monitor. Этап нужен для наблюдения за бизнес-процессом, чтобы понять, достигли ли мы поставленной цели.

5. Оптимизация — Optimize. Когда собрали достаточно цифр и фидбэка, можно приступать к новому циклу оптимизации. Это касается минорных доработок: например, если мы увидели, что в бизнес-процессе есть узкое горлышко, мы можем избавиться от него и быстро внедрить в существующий процесс. Если же процесс устарел и требует реновации, можно запустить новый BPM-цикл с первого этапа.

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

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

Теория закончилась — переходим к лайфхакам. Я буду рассматривать их в привязке к BPM-циклу.

Как проектировать или искать проблемы

С чего начать, если бизнес просит нас оптимизировать процесс N.

Соберите потребности. Это максимальная база для бизнес-аналитиков, про которую иногда забывают. Если коллеги пришли с жалобами на процесс, сначала лучше посмотреть, а правильно ли они работают по этому процессу? Может оказаться, что заказчик просто действует неправильно, и тогда проблема решается инструкцией или проведением демо для пользователей процесса. Не зря говорят, что лучшая задача — та, которую не пришлось делать. 

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

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

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

Как моделировать или визуализировать будущее

Начинаем готовить процесс в состоянии To be.

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

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

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

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

2. Докупить мощностей серверов и нанять людей, когда оптимизировать уже некуда.

3. Забить и принять как данность — просто учитывать эти ограничения в контексте разработки процесса. 

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

Учтите риски. Они делятся на четыре вида: юридические, финансовые, технологические и человеческие. 

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

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

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

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

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

Представьте, что компания просит вас оптимизировать процесс выдачи справок.

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

Первое, что приходит на ум: разумеется, надо генерировать справки автоматически! Прикрутим скрипт, который будет разбирать почту, бэк начнет генерировать справки, подписывать будем ЭЦП, а потом отсылать назад на почту. Красота! 

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

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

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

Как внедрять и считать успех

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

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

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

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

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

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

А всех, кому текст показался банальным, я зову работать в Tinkoff Mobile Core.