Есть на свете такая штука, называется «бизнес-программирование». Я вам о ней еще не рассказывал. И не уверен, что вам она будет интересна.
Бизнес-программирование — это программирование бизнеса, как системы. Вот вы же чего-то программируете? Сервис там, сайт, мобильное приложение, корпоративную систему. Она работала, никого не трогала, а вы — раз, и изменили чего-то, и стало лучше, быстрее, удобнее. Ну, или… Всяко ведь бывает.
Аналогично можно менять бизнес, принципы те же самые. Только есть отличия в деталях. Например, там есть люди, которые ни черта не хотят делать. И даже слушать вас не хотят. И вообще не хотят ничего, кроме получки, сериала про ментов и пиваса.
Короче, статья экспериментальная. Понравится — напишу еще. У меня целый учебник есть по бизнес-программированию. Не понравится — хрен с ним, переживу. Итак, погнали.
Умение анализировать и оптимизировать процессы – одно из ключевых для бизнес-программиста. И так удачно совпало, что работа с процессами – самая простая, понятная и легко воспроизводимая часть всей методики бизнес-программирования.
Вероятно, потому, что внутренние процессы предприятия, по сути своей, очень похожи на процессы, протекающие в инженерных системах, в том числе – в прикладных решениях, вроде конфигураций 1С. Везде есть старт, финиш, действия, исполнители, условия, переходы и возвраты. В ПО, разумеется, исполнители – не люди, а более широкий набор объектов – документы, модули, серверы, разные программы, узлы распределенной системы и т.д.
Схожесть принципов работы процессов порождает важный вывод – методы оптимизации во многом идентичны, равно как и требования к процессам. Например, и человеческий, и программный процесс должны идти быстро. Человек не хочет ждать исполнения заявки в соседнее подразделение больше суток, а главный бухгалтер не хочет ждать расчета себестоимости дольше 15 минут.
Публикация, которую вы читаете – выдержка из учебника по бизнес-программированию. Она, вероятнее всего, отличается от моих предыдущих публикаций, т.к. не является развлекательной, мотивирующей или провоцирующей. Это – лишь изложение конкретного, понятного, простого и легко применимого метода.
Метод плавательных дорожек
Метод плавательных дорожек – неплохое средство для анализа процессов. Это – именно аналитический метод, т.к. он не говорит, что надо изменить в процессе, но позволяет легко и быстро увидеть потенциальные источники проблем.
В основном применим для кроссфункциональных процессов – тех, в которых участвует два и более функциональных подразделений, либо команд – в общем, там, где процесс переходит через какие-то границы.
Рассмотрим на примере. Допустим, у нас есть некий процесс – закупки под заказ. Менеджер отдела продаж получил заявку от клиента, менеджер отдела закупок должен найти поставщиков, узнать цены и сроки, согласовать их с нашим продавцом, получить счет на оплату, отдать его в финансовый отдел, согласовать с ними и поставщиком условия оплаты, оформить заказ поставщику, и дождаться завершения – оплаты и, собственно, прихода нужных товаров.
Допустим, заказчиком, т.е. менеджером по продажам, обозначены проблемы процесса, на обывательском языке. Ключевой названа проблема скорости – очень уж долго ждать исполнения заявки на закуп. Когда процесс завершен, и создан заказ поставщику, проблем особо нет – поставщики надежные, подводят редко. Но этапы согласования, движения заявки внутри компании – никуда не годятся.
Нарисуем упрощенную схему этого процесса, в виде таблицы.
Что можно сказать, глядя на этот процесс? Какие видны проблемы – реальные или потенциальные? Вроде, процесс достаточно стандартный, в том или ином виде встречается на большинстве предприятий. Где теряется скорость?
И еще один вопрос: как увидеть потенциальные проблемы процесса, не зная содержания колонки «Действие» — имея информацию только об исполнителях? Провести этакий экспресс-анализ, на лету, без погружения в детали выполняемых действий.
Вот тут и пригодится метод плавательных дорожек. Название взято по аналогии с дорожками в плавательных бассейнах, разделенных волногасителями – канатами яркой раскраски, протянутыми на всю длину бассейна.
В нашем методе дорожки – это разные функциональные подразделения. В общем случае, это могут быть даже разные люди внутри одной команды или службы.
Нарисуем тот же самый процесс по методу плавательных дорожек, оставив только номера действий и исполнителей. В нашем случае исполнителей – три, столько же будет и дорожек. Процесс идет сверху вниз, номер действия стоит в колонке его исполнителя.
Пока ясности не добавилось. Видно только, что больше всего действий выполняет менеджер по закупкам. Видны потенциальные проблемы процесса, где он теряет свою скорость, застревает или вообще теряется? Нет, чего-то не хватает.
Попробуем добавить стрелки – направления перехода между действиями. Сплошной линией обозначим основные переходы, пунктирной – вспомогательные, на случай сбоев в процессе и возвратов к предыдущим действиям (например, если продавца не устроят цены, предложенные поставщиком).
Со стрелками процесс выглядит несколько менее читаемым, но в целом понять его можно, если водить пальцем по стрелкам от цифры к цифре. Сейчас, глядя на эту картинку, можно понять, где находятся узкие места? Нет, пока они не видны.
Вернемся к аналогии с плавательными дорожками в бассейнах. Если вы – взрослый, серьезный и адекватный человек, пришли в бассейн, чтобы вволю поплавать, потренировать пятидесятиметровку брасом, кто способен отвлечь вас от этого процесса и вывести из себя? Вы выбрали дорожку, на которой меньше всего людей, или вообще никого нет, и приготовились получать удовольствие.
Но вы – не один такой, и вот какой-то умник тоже ныряет в вашу дорожку. За ним – еще один, затем еще и еще. И вот плавать становится решительно невозможно – приходится ограничивать свои движения, чтобы не задевать чужие мокрые руки и бока.
Вы вынуждены менять дорожку. Вроде ничего страшного – переплыли под волногасителем, возможно не один раз (если свободная дорожка – не смежная с вашей), и снова наслаждаетесь процессом. Но вот ситуация опять повторяется – набежали люди, и снова вам мешают. Ситуация усугубляется наплывом детей, которые вовсе не собираются торчать все время на одной дорожке – они будут играть, дурачиться, нырять, на спор переплывать поперек несколько дорожек и т.д.
За время сеанса плавания вам придется несколько раз поменять дорожку, проплывая под волногасителем.
В случае с процессами смена дорожки – это переход потока действий через границы. В качестве границы мы выбрали функциональные подразделения. В бассейне вам нужна пара секунд, чтобы сменить дорожку, но в условиях внутренних процессов предприятия на такое преодоление могут уходить часы, дни, иногда – недели.
Посмотрим на финальную картинку процесса – то же, что и в прошлый раз, только обозначим крестиками моменты перехода от одной дорожки к другой.
Итого, 5 крестиков на основных действиях, 4 – на вспомогательных, всего (максимум) – 9. Девять раз процесс вынужден преодолевать границы функциональных подразделений.
Каждое пересечение границы – это потеря. Теоретически – это потенциальная потеря, т.к. бывают в жизни тщательно настроенные процессы, которые текут, не запинаясь на границах. Но на практике смена дорожки – это всегда потеря в скорости.
Физический процесс перехода не будем считать ограничением – сейчас, в большинстве случаев, этот процесс автоматизирован. Заявки, счета на оплату, расценки и т.д. передаются в электронном виде, т.е. мгновенно.
Но передача информации – это лишь начало ожидания на границе. Каждая дорожка, т.е. подразделение или исполнитель, живут своей жизнью, по своим правилам, регламентам и внутренним процессам. Почти везде фигурирует понятие очереди.
Менеджер по закупкам не бросается расценивать каждую заявку сразу при получении. У него этих заявок – два десятка в день. Соответственно, заявки выстраиваются в очередь на обработку. Если сотрудник склонен к оптимизации своей работы, он будет заявки группировать – например, выберет одинаковые позиции для заказа из нескольких заявок, и сделает запрос поставщику.
Финансист, точно так же, не работает с каждой заявкой индивидуально, особенно на этапе оплаты. Перечисление денег поставщикам выполняется по реестру, и обычно – один или два раза в день. Соответственно, в очереди на оплату счет простоит, как минимум, один день. При сложной процедура согласования и бюджетирования – например, если заявки на оплату нужно подавать за неделю – процесс может очень серьезно застрять на границе.
Даже не глядя на конкретные должности и особенности их работы, всегда есть задержка в реагировании на информацию – как минимум, потому, что человек не видит ее сразу, в момент передачи. Мало кто сидит за компьютером и сразу читает всю входящую почту. Некоторые вообще за компьютером почти не сидят – тот же продавец, может уехать на встречу с клиентом, и сутки не выполнять действие № 5 (анализ прибыльности сделки).
Как было сказано в начале, метод не дает ответа на вопрос «как изменить процесс?», но потенциальные проблемные места показывает очень четко. Как вы теперь видите, метод еще и очень прост в применении.
Немного потренировавшись, вы сможете посчитать количество точек перехода за несколько секунд, ничего не рисуя – просто глядя на описание процесса, в каком бы виде оно не было исполнено.
Некоторые форматы, или нотации описания процессов, особенно наглядны, и буквально просят о том, чтобы кто-то посчитал дорожки и переходы между ними. Например, квалиграммы.
Метод плавательных дорожек можно применять, например, на собеседовании – если вы пришли в новую для себя компанию, и претендуете на должность или деятельность, связанную с процессами. Просто попросите показать вам описание проблемных процессов (если работодатель сам этого не сделал), или нарисовать маркером на доске.
После чего, загадочным голосом произнесите: «Хороший процесс, только я вижу здесь, как минимум, 12 потенциально опасных точек» и покажите эти точки. Тут можно кратко рассказать о методе, его назначении и основных принципах. На вопрос «А как можно оптимизировать этот процесс?» будет достаточно ответа «Вариантов несколько, но нужно более глубокое погружение в детали».
Хотя, конечно, можно сразу дать и более точные рекомендации – методы контроля границ, о которых мы поговорим далее.
Автор: nmivan
