Описание бизнес-процессов
Существуют некоторые принципы, которых следует придерживаться при описании бизнес процессов:
- описываются только сформированные на предприятии бизнес-процессы;
- в первую очередь выполняется моделирование схем;
- моделирование процессов отвечает уровням детализации.
Степень детализации выбирает менеджер, руководствуясь своим опытом. Выделяют 5 уровней анализа:
- Операция – мельчайшая единица деятельности, например, переключение тумблера, другой пример – копирование данных.
- Действие – ряд операций, требующих контроля и выполняемых последовательно.
- Процедура – ряд действий, выполняемых последовательно, в итоге которых получаем конкретный результат.
- Бизнес-процесс базового уровня – цикл процедур, связанных друг с другом, приводящий к существенному для компании результату и имеющий нескольких исполнителей.
- Направление деятельности – самая крупная единица деятельности компании, которая включает ряд групп бизнес процессов.
Описание бизнес-процессов проходит в 11 шагов. Разберемся, что делает бизнес-аналитик на каждом из них.
Как понять, что компания готова участвовать в описании и оптимизации процессов?
Антон Мартьянов, член союза интерим-менеджеров, консультант в области бизнес-процессов OpenTRM:
Для этого должно совпасть четыре момента: готовность компании, сотрудников, собственников и наличие выделенного на внедрение бюджета. Готовность компании выявляется в ходе аудита. Готовность сотрудников, хотя бы на уровне руководителей, увидеть сложнее.
С первого взгляда все будут улыбаться и махать, но при внедрении нас ожидает прокрастинация и саботаж! Прояснить этот момент помогает интервьюирование с ключевыми владельцами процессов: есть описание процессов или нет, есть должностные инструкции или нет…?
Константин Зусманович, управляющий партнер Financial Mechanics:
Компания, по большому счету, готова к внедрению, если:
- Управляющая команда понимает и суть процессного подхода, и необходимость его внедрения, и сопряженные с таким внедрением риски сложности, и свою роль в подобном проекте.
- В компании есть явная неудовлетворенность линейных руководителей и рядовых сотрудников «бардаком», сложностями в коммуникациях между подразделениями, взаимные претензии к качеству передаваемых друг другу результатов.
- Чем крупнее компания, тем важнее в подобном проекте IT-составляющая, связанная с реальным контролем процессных KPI и SLA, организацией потоков информации…
Оксана Дажун, бизнес-тренер, директор Dajun Consulting:
Компания готова, если соответствует следующим критериям:
- Руководство компании осознает актуальность и своевременность. Создает рабочую атмосферу, включая формирование выделенной группы совершенствования управления, готово сформировать в компании необходимую группу ключевых специалистов.
- Руководство и заинтересованные подразделения понимают сложность и продолжительность проекта, и, как следствие, невозможность быстрого получения результатов.
- Руководство готово к перераспределению функций и ответственности между структурными подразделениями, необходимому при построении системы бизнес-процессов.
- На этапе внедрения бизнес-процессов подразделения компании готовы к параллельному ведению работ по бизнес-процессам в прежнем формате и обновленном.
Ольга Якимова, бизнес-тренер, автор методик и проектов в области менеджмента и маркетинга:
Перед внедрением системного подхода я предлагаю руководителям в течение нескольких дней фиксировать, какие вопросы они решают. С какими проблемами приходят сотрудники? Какая доля из них озвучивалась многократно? Например, нарушение трудовой и исполнительской дисциплины, срыв сроков по проектам или переваливание ответственности: с сотрудника на сотрудника, с отдела на отдел. Если есть эти симптомы – пора описывать, оптимизировать и систематизировать все процессы.
Почему внедрение бизнес-процессов может завершиться неудачно?
Антон Соколов, технический директор IT-компании «Деасофт»:
Бывают случаи, когда собственник хочет поиграть во внедрение, на какое-то время почувствовать себя управленцем. Если для собственника это игра, то проект, скорее всего, не будет доведен до конца, не хватит энтузиазма. Распознать такие мотивы на первых этапах невозможно, но к середине проекта начинают вылезать неочевидные проблемы. Как правило, в таких проектах успешно завершается техническая часть, а до внедрения так и не доходит.
Антон Мартьянов, член союза интерим-менеджеров, консультант в области бизнес-процессов OpenTRM:
Самое главное во внедрении – это люди, «человеческий фактор», причем как со стороны заказчика, так и со стороны подрядчика. Одна из самых частых ситуаций – сэкономили на специалистах. На втором месте – исключили из проекта самую дорогую и длинную фазу – обучение пользователей.
Ольга Якимова, бизнес-тренер, автор методик и проектов в области менеджмента и маркетинга:
Часто собственники в иллюзиях думают, что, разработав процессы один раз, решают проблему навсегда. Это не так. Мир меняется. Компания меняется. И надо быть готовыми корректировать процессы с течением времени.Другая распространенная ситуация – хотели, горели, прописали…, но не сделали.
Оксана Дажун, бизнес-тренер, директор Dajun Consulting:
Спотыкаются компании, которые внедряют бизнес-процессы самостоятельно. Хорошо, если есть специалисты среди своих, но если компания сталкивается с этим первый раз, то самостоятельно внедрять не рекомендуется.
Самые частые ошибки:
- Недостаточное понимание уровня детализации. Описание бизнес-процессов должно происходить, начиная с более высокого уровня, заканчивая самым низким. Необходимо понимать слойность этих уровней. Компании спотыкаются, когда начинают с высокого уровня, сразу уходя в детализацию, и запутываются в ней. А надо идти послойно: снял один уровень, затем следующий. Так до необходимой глубины детализации. Начинать надо сверху, крупными мазками, чтобы увидеть всю структуру целиком, иначе описать бизнес-процессы практически невозможно.
- Некоторые компании экономят на консультантах, думая, что сами смогут все описать. В итоге это дольше и дороже. А самое грустное, что разочаровываются в описании бизнес-процессов и перестают применять как инструмент.
Константин Зусманович, управляющий партнер Financial Mechanics:
Причин неудач в подобных проектах – огромное множество. Наиболее неожиданная и частая для не очень опытных в этой области коллег – недооценка важности «принятия» как самого проекта, так и создаваемых/ оптимизируемых процессов их ключевыми участниками.
Я лично видел подобный провальный проект, который проводило крупное консалтинговое агентство для одной из крупнейших российских компаний, и проект «рухнул» именно по этой причине. С «технической» стороной – с описанием процессов, все было в полном порядке, но были разногласия в руководящей команде клиента, а часть сотрудников консультанта игнорировали базовые ожидания клиента. Все это породило неприятие и консалтинговой компании, и проекта как такового. Что и определило его провальное завершение.
Думать гипотезами, а не большими планами
Гибкий подход — постоянное итеративное развитие: делаем шаг, осматриваемся, принимаем решение, делаем следующий шаг. Но как понять, как именно нужно развивать продукт, какие функции добавлять, как дорабатывать модель?
Даже если на старте у предпринимателя в голове есть дорожная карта, он не знает наверняка, что именно сработает и принесёт деньги. Следовать поэтапному, но неизменному плану — неустойчивый подход.
Например, после запуска может оказаться, что экономика проекта отрицательная — за привлечение клиента приходится платить больше, чем бизнес зарабатывает с него. Если продолжать двигаться по изначальному плану, компания будет терять деньги на каждом клиенте и масштабировать минуса
Чтобы сохранить гибкость, предприниматель делает небольшие шаги на основе гипотез: ищет, какое решение может быть востребовано на рынке и как его можно реализовать. Гипотеза может касаться нового модуля в продукте, нового канала продвижения или сегмента, нового подхода к процессу.
Важно, чтобы в гипотезе было конкретное предположение: как действие повлияет на продукт или компанию. Гипотеза состоит из двух частей: Если [сделать что-то], то [мы получим такое-то изменение в продукте или процессах].
Например:
- «Если мы сделаем конкретный оффер на узкую аудиторию, сможем снизить стоимость привлечения на 10%».
- «Если в продукте появится возможность приглашать друзей, мы сможем привлекать на 5% больше новых пользователей в месяц за счёт рекомендаций».
- «Если мы добавим ежедневные пуш-уведомления, то сможем повысить частоту использования продукта и удержание пользователей».
Гипотезу можно быстро проверить. Не придётся разрабатывать что-то месяцами: на запуск хватит нескольких дней или даже часов, останется только оценить результат и принять решение о следующем шаге. Если гипотеза оправдает себя и принесёт положительный результат, её можно взять в работу и развивать. Если результата не будет или он будет отрицательным, откатитесь назад и проверяйте следующую гипотезу.
Опираться на метрики
В основе гибкости лежит здравый смысл. У предпринимателя нет задачи проверять все гипотезы, которые он сможет придумать. В первую очередь нужно работать над предположениями, которые смогут значительно усилить бизнес или продукт.
Для этого нужно определить список приоритетных метрик — количественных показателей, с помощью которых вы оцениваете состояние продукта или бизнеса. Например, конверсия и рентеншен, чтобы следить, улучшают ли нововведения пользовательский опыт. Или стоимость привлечения и средний чек, чтобы контролировать юнит-экономику.
Если предприниматель не выбрал метрики, он двигается вслепую: не знает, принесли ли предыдущие шаги положительные изменения, не может планировать следующие.
Метрики помогают принимать решения. Например:
Метрика — конверсия. Гипотеза — меняем позиционирование продукта на лендинге. Проверили гипотезу и увидели, что конверсия упала — отказываемся от идеи.
Метрика — конверсия. Гипотеза — упрощаем форму регистрации. Проверили гипотезу и конверсия, наоборот, выросла — отлично, идём в нужную сторону.
- Метрика — средний чек. Гипотеза — переработать тарифы. Ввели новые тарифы, вырос средний чек — здорово, гипотеза сработала.
Часто молодые проекты смотрят только на выручку. Это нормально на самом первом этапе, когда ещё непонятно, востребована ли модель. Но от этого подхода со временем стоит уходить. Выручка — верхнеуровневая метрика, которая опирается на много других. Из-за этого ей достаточно сложно управлять, она не показывает детали состояния продукта и бизнеса.
Например, можно разложить выручку на средний чек и количество клиентов. Количество клиентов — на конверсию и трафик на сайте. Получается, выручка зависит как минимум от трёх других показателей, каждым из которых бизнес может управлять. Если смотреть на одну выручку, то можно не заметить, что средний чек, например, растёт, а конверсия падает. И не понять, что отдел продаж работает хорошо, а маркетинг — хуже.
Чем раньше бизнес начинает смотреть на низкоуровневые метрики, тем больше рычагов управления бизнесом у него появляется. Тем проще предпринимателю принимать решения и сохранять гибкость.
Safe 5 – ваша операционная система для business agility
Организуя вторую операционную систему вокруг потоков ценности, а не департаментов (отделов), Scaled Agile Framework® предлагает предприятиям возможность сосредоточиться на клиентах, продуктах, инновациях и росте. Кроме того, сама эта операционная система является гибкой.
Она построена на проверенных временем практиках Lean, Agile, SAFe и может организовываться и быстро реорганизоваться, не нарушая полностью существующую иерархию. Это то, что и требует business agility. Однако, для достижения этой цели организации необходима значительная экспертиза в семи основных компетенциях для цифровой эпохи.
Каждая компетенция может обеспечить доставку ценности самостоятельно, однако истинная гибкость бизнеса может присутствовать только тогда, когда предприятие достигает значительного мастерства во всех компетенциях. Это непростая задача, но путь к business agility очевиден.
Каждая из этих компетенций обеспечивает знания, навыки и поведение, которые позволяют предприятиям достичь гибкости бизнеса.
Компетенция Lean-Agile Лидерство (Lean-Agile Leadership) описывает, как Lean-Agile лидеры стимулируют и поддерживают организационные изменения, предоставляя отдельным сотрудникам и командам возможность достичь своего наивысшего потенциала.
Они делают это, вдохновляя собственным примером, применяя Lean-Agile мышление и управляя изменениями в построении новых способов работы. Результатом является более вовлеченные сотрудники, повышение производительности и инновации, а также успешные организационные изменения.
Компетенция Культура Непрерывного Обучения (Continuous Learning Culture) описывает набор ценностей и практик, которые побуждают отдельных лиц и предприятие целиком постоянно повышать знания, компетентность, производительность и инновации.
Компетенция Командная и Техническая Гибкость (Team and Technical Agility) описывает критически важные навыки, Lean-Agile принципы и практики, которые высокопроизводительные Agile команды и команды Agile команд используют для создания высококачественных решений для своих клиентов.
Компетенция Agile Доставка Продукта (Agile Product Delivery) — это клиентоцентричный подход к определению, созданию и выпуску непрерывного потока ценных продуктов и услуг для клиентов и пользователей. Эта компетенция позволяет организации предоставлять решения, которые радуют клиентов, снижают затраты на разработку, уменьшают риски и оставляют позади конкурентов.
Компетенция Доставка Решения уровня Предприятия (Enterprise Solution Delivery) описывает, как применять принципы и практики Lean-Agile к спецификации, разработке, развертыванию, эксплуатации и эволюции крупнейших в мире и наиболее сложных программных приложений, сетей и киберфизических систем.
Компетенция Бережливого Управления Портфелем (Lean Portfolio Management) выравнивает стратегию и выполнение, применяя подходы бережливого и системного мышления к стратегии и инвестиционному финансированию, операционной деятельности и управлению Agile портфелями.
Компетенция Организационная Гибкость (Organizational Agility) описывает, как Lean-мыслящие люди и Agile-команды оптимизируют свои процессы, развивают стратегию с четкими и полными новыми обязательствами и быстро корректируют организацию по мере необходимости, чтобы извлечь выгоду из новых возможностей.
Каким компаниям вы отказываете в проекте по внедрению бизнес-процессов?
Антон Соколов, технический директор IT-компании «Деасофт»:
Отказывать в проектах по внедрению бизнес-процессов приходится довольно часто. Среди собственников бытует мнение, что внедрение процессного подхода или автоматизация сразу помогут навести порядок и снизить издержки. На практике же наоборот: расходы увеличиваются, появляются новые рабочие места, сотрудники объявляют итальянскую забастовку.
Ольга Якимова, бизнес-тренер, автор методик и проектов в области менеджмента и маркетинга:
Есть одна серьезная проблема при внедрении процессного подхода, о которой не принято говорить. Если в потенциальной системе присутствуют те, кто «в домике»: родственники, друзья и иные лица, которые имеют какое-то отношение к ЛПР, участвуют в процессах компании и при этом не профессиональны.
Я всегда спрашиваю у заказчика (собственника) о степени свободы моих действий и о его готовности слышать правду. Я как доктор, мне важно поставить реальный диагноз системе управления и назначить эффективное лечение, иначе результата не будет. Можно ли справиться с этой проблемой? Можно.
Собственник имеет право в своем бизнесе делать все, что угодно. В том числе принимать на работу родственников и друзей, чей профессионализм не соответствует занимаемой должности. Просто тогда я советую вывести их из системы управления. Пусть будут советниками, экспертами, кем угодно, но пусть от их непрофессионализма не зависит результат бизнеса.
Оксана Дажун, бизнес-тренер, директор Dajun Consulting:
Отказываю не компаниям, а собственнику. Если собственник равнодушен или наоборот – проявляет рвение, но настоящую потребность не проговаривает и не осознает, то я не могу ничем помочь.
Когда у меня было меньше опыта, мне казалось, что бизнес-процессы можно описать со стороны. На самом деле важно участие непосредственных хозяев процесса. Здесь важна и квалификация, и заинтересованность, и детальность. На одном энтузиазме того, кто ведет такой большой проект, вытянуть невозможно.
Антон Мартьянов, член союза интерим-менеджеров, консультант в области бизнес-процессов OpenTRM:
Лично я и моя команда отказывают двум основным категориям:
- «Нерешительным» компаниям, которые долго принимают решение и отнимают время у подрядчика. Существует семь шагов к успешному внедрению и алгоритм выхода на проект. Когда со стороны заказчика происходит отклонение от намеченных шагов и алгоритма, затягивается время, это выливается в удорожание проекта, так как каждое обращение и время переговоров закладывается в накладные расходы.
- «Бедным» компаниям, которые хотят ужаться и выкинуть какие-то этапы из проекта. Раньше, в порывах добрых чувств и большом желании получить проекты, мы пытались совместно «вписаться в бюджет» и пойти на встречу. В итоге все обвинения в неудачах все равно сыплются на подрядчика. Я таким компаниям говорю – ищите начинающих консультантов в поиске первых проектов и упражняйтесь совместно, но и риски берите на себя.
Тимур Гасиев, антикризисный менеджер, эксперт в области АПК:
Как правило, я отказываю компаниям, если вижу, что топ-менеджерам или собственникам это не нужно. Инициатива внедрения бизнес-процессов должна исходить, в первую очередь, от них или хотя бы активно поддерживаться. Во-первых, руководители должны донести до сотрудников важность данного мероприятия и вдохновить их в нем участвовать.
Во-вторых, даже самые опытные консультанты не могут знать всех нюансов деятельности предприятия, поэтому, чтобы внедрить эффективные бизнес-процессы, необходима вовлеченность руководства. Бессмысленно что-то предлагать, если управленцы не заинтересованы в оптимизации, построенная модель все равно не будет поддерживаться и работу можно считать напрасной.
Какую роль играет собственник компании при сотрудничестве с консультантом?
Антон Соколов, технический директор IT-компании «Деасофт»:
При сотрудничестве с консультантом важно, чтобы собственник вышел за рамки оперативной текучки и посмотрел на компанию глазами инвестора, четко знал, как часто и по каким критериям он хочет контролировать работу бизнеса, был готов проявить силу и убедить сотрудников в необходимости предстоящих перемен.
Антон Мартьянов, член союза интерим-менеджеров, консультант в области бизнес-процессов OpenTRM:
В каждой ситуации собственник играет разную роль: где-то присутствует просто на уровне одобрения, где-то на уровне выделения бюджета, где-то сам принимает активное участие как ключевой управленец. Однако чаще всего собственники – консерваторы и мешают тем изменениям, которые хочет произвести команда топ-менеджеров.
И это самая распространенная ситуация в моей практике. И если топ-менеджеры способны подготовить расчеты выгод от внедрения в цифрах, то сходить на защиту проекта и развеять сомнения, убрать страхи зачастую под силу только специально привлеченному специалисту. На многих проектах этим правилом пренебрегают, экономят на этом звене – а потом все страдают.
Александр Гончаров, старший бизнес-архитектор ICL Services:
Собственник компании должен быть либо инициатором проекта по описанию процесса, либо должен активно его поддерживать. Незаинтересованность собственника в проекте может говорить об отсутствии реальной бизнес-потребности, и сигнализировать о потенциальной неудаче проекта. Чем меньше масштаб бизнеса, тем больше роль собственника.
Владислав Моргунов, главный специалист отдела внедрения процессного управления «Сиам консалтинг»:
Если собственник не отстранен от управления компанией, то он лидер изменений и самое заинтересованное лицо в оптимизации процессов. Сильная поддержка со стороны руководства – наиболее критичный фактор успеха. При отсутствии вовлеченности руководства вся ответственность перекладывается на консультантов.
Кейсы неудачного внедрения бизнес-процессов
Александр Гончаров, старший бизнес-архитектор ICL Services:
Поступил заказ на регламентацию процессов от собственника среднего по масштабам бизнеса (производственная компания, порядка 100 человек). Интерес был реальный. В ходе реализации пилотного проекта возникли сложности при утверждении регламентов процессов, спровоцированные самим собственником.
В итоге выяснилось, что собственник, являясь также генеральным директором, был сторонником ручного управления бизнесом и обожал вмешиваться в работу компании на любом участке. Когда пришло осознание, что регламентация процессов не улучшит управление компанией, так как собственник и дальше будет вмешиваться в ход бизнес-процессов в нарушение регламентов, проект пришлось свернуть.
Тимур Гасиев, антикризисный менеджер, эксперт в области АПК:
Приведу пример неудачного внедрения бизнес-процессов. Собственник компании, работавшей в оптовом канале, увидел бизнес-модель по работе в рознице с помощью планшетов (система «Чикаго»), нашел российский аналог и начал работать по этой системе. В итоге, чего и следовало ожидать, компания потерпела колоссальные убытки.
В данном случае собственник допустил самые серьезные ошибки, которые привели к плачевным результатам по следующим причинам:
- Отсутствовал персонал для работы в данном канале.
- Не хватало опыта работы в подобном канале.
- Качество не соответствовало.
- Российский аналог «Чикаго» оказался непригодным для использования.
- Компания в целом была не готова к внедрению новых процессов. Менеджеры не смогли придерживаться установленной модели. Выделенных финансов оказалось недостаточно.
Мотивация разработчиков
Схема строится на удовлетворении у сотрудников чувства собственной важности, для чего используются старые и хорошо зарекомендовавшие себя психологические методы.
Для команд будет взращиваться идея работы в самостоятельной, способной решить полный спектр задач «боевой единице», которая, в случае чего может и поспорить с бизнесом. Здесь бизнесу важно, не отклоняясь от курса, периодически принимать идеи команды в мелочах.
Например, приветствовать возможность выбирать стек разработки, одобрять некритичные решения по функционалу или дизайну ПО и так далее. Необходимо дать людям веру, что их мнение ценят и слышат, а также поддерживать их убежденность в автономности собственной работы. В этом случае каждый из сотрудников будет вовлечен в работу группы на достаточном уровне, чтобы сохранять знания.
Разбор принятых технических решений и возникших сложностей на регулярных ретроспективах позволит команде представлять происходящее на соседних участках и при необходимости включиться в работу, а исполнителю усложнит возможность утаить важные нюансы. Также это позволяет в определенных пределах повысить качество разрабатываемого решения.
Еще одной важной целью является точечная групповая диагностика, позволяющая понять особенности происходящего группового процесса и скорректировать его, направив энергию сотрудников в нужное русло. Впрочем, разработчики в массе своей ретроспективы очень не любят, и крайне важно организовать их таким образом, чтобы происходящее не было для сотрудника стрессовым фактором.
Это мероприятие может быть для них очень мотивирующим и вдохновляющим, если проводить его в максимально позитивном ключе, начиная встречу, при возможности, с транслирования руководителем энтузиазма и гордости за проделанную командой работу. Главное — чтобы люди охотно делились друг с другом деталями.
Внутренние конференции могут позволить себе только крупные игроки, но они дают разработчикам возможность блеснуть профессионализмом перед своими коллегами и почувствовать себя оцененными по достоинству. Для компаний с небольшим количеством разработчиков в 10-20 человек отлично подходит организация внутренних «курсов» по смежным дисциплинам, на которых, например, фронтенд-разработчик может прочитать несколько лекций по vue.js для своих коллег, программирующих бекенд на .net core.
«Преподаватель» в этом случае сможет удовлетворить свою потребность в признании, «студенты» получают возможность профессионально расти и пробовать новое, а бизнес вдобавок к возросшей вовлеченности сотрудников совершенно бесплатно получает более квалифицированные кадры, знакомые притом с не затрагивавшими их раньше аспектами работы.
Ведение внутренней базы знаний — сложная и требующая времени задача, а полнота информации зависит исключительно от вовлеченности участвующих в ее дополнении. Актуальная база знаний не может быть заполнена в директивном порядке, и самый действенный вариант — сделать актуализацию данных почетной.
Для этого подойдет использование «внутренней валюты» (условных звездочек-наград, которые можно на что-то обменять), публичная похвала («Вася 2 месяца назад по твоему вопросу все очень здорово описал, посмотри в wiki»). Основное — участвующие в ведении базы знаний сотрудники должны быть убеждены, что их ценность для компании от этого растет.
Нотации моделирования бизнес-процессов
Существуют стандартизированные условные обозначения или нотации бизнес-процессов, которые используются во всем мире.
- BPMN – помогает демонстрировать бизнес-процесс представителям разных аудиторий.
- SADT – используется для создания функциональной модели.
- DFD – стандарт для макропроцессов в бизнесе.
- WFD – стандарт для бизнес-процессов нижнего уровня с возможностью демонстрации последовательности работ с учетом времени.
- ARIS – применяется для создания, анализа, внедрения и улучшения бизнес-процессов.
- EPC – показывает вход и выход процесса в ходе моделирования сложных комплексов.
- STD – показывает, как ведет себя система при внешнем управляющем воздействии.
- UML – описывает требования к ИС.
- ERM – описывает концепцию бизнес-процесса.
- FCD – описывает действия, исполнителей, оборудование и данные с помощью символов.
- RAD – описывает и анализирует функциональные элементы, наглядно демонстрирует их взаимодействие.
- ANSI – набор блок-схем для демонстрации хода процесса.
- IDEF – набор инструментов для разделения и объединения блоков (IDEF0), изображения процесса (IDEF3) и др.
- Unified Modeling Language – средства визуализации, конструирования, документирования систем и процессов.
- Цветные сети Петри – демонстрируют переходы, изображают события и действия.
- Дорожки Брюса Силвера – дополнение к другим нотациям, применяется, чтобы показать, как переходит ответственность от одного участника к другому.
- Карты потоков создания ценности – набор условных обозначений, которые показывают затраты времени и ресурсов.
Пятый страх: «всё это бесполезно — мы только потратим время»
Это то, с чем вы будете бороться на каждом собрании рабочей группы до первых результатов. В производственном агентстве собирать каждую неделю на 2-3 часа команду из пяти человек, в составе которой технический директор, аккаунт-менеджер, директор по производству, ведущий дизайнер и менеджер по продажам, удовольствие не из дешёвых. Распишите для себя выгоды, которые получат все от четко работающих процессов.
Для себя мы обозначили это так.
Собственники бизнеса
Чем быстрее и лучше мы наладим процессы, тем скорее сможем уйти от операционной деятельности без ущерба качеству. Появится возможность уделять больше времени стратегическому планированию и развитию. Улучшится атмосфера в компании, её корпоративная культура.
Руководители разных уровней
Перестанут вязнуть в текучке — работа подчинённых будет хорошо выполняться без жёсткого контроля и ручного управления. Смогут контролировать показатели и обосновывать управленческие решения. Будут тратить меньше времени на ввод нового сотрудника. Придёт осознание общего вектора развития и процессов компании в целом.
Рядовые сотрудники
Процессный подход позволит выстроить эффективную работу в компании по горизонтали — между сотрудниками и отделами. Появится возможность реализовывать свой творческий потенциал и расти профессионально, активно участвуя в развитии компании. Новички, только пришедшие в компанию, смогут быстрее разобраться в процессах. Сотрудники начнут понимать, в каком направлении развивается компания и как устроены её процессы.
Клиенты и партнёры
Всегда приятно работать с бизнесом, в котором все процессы отработаны, понятны и прозрачны. Клиент получает совершенно другой уровень сервиса и качества конечного продукта.
Реинжиниринг и постоянное совершенствование
Каждая компания уникальна, поэтому нельзя закрепить четкий порядок реинжиниринга, который будет актуален для всех. Но можно выделить 5 основных этапов, на которые могут ориентироваться предприятия, планируя реинжиниринг бизнес-процессов.
- Определяем потребности компании и основания для проведения реинжиниринга. Здесь нужно провести анализ и понять, что в бизнес-процессе идет не так.
- Формируем группу. Можно найти специалистов со стороны или задействовать своих компетентных сотрудников.
- Намечаем основные бизнес-процессы. Здесь важно точно выявить проблемы, понять потребности клиентов, сформулировать задачи и цель компании.
- Меняем подход. Нужно пересмотреть тактику создания бизнес-процесса и его реализации, при необходимости не ограничиться улучшением прежнего алгоритма, а полностью изменить ее.
- Подключаем сотрудников. Реинжиниринг требует тестирования, а работники, которые будут непосредственно реализовывать обновленную схему, дадут обратную связь.
Реинжиниринг – управленческий метод, который позволяет исправлять проблемы по мере их возникновения. Одновременно можно реинжинирить до 20% от общего числа бизнес-процессов на предприятии.
Постоянное совершенствование, напротив, позволяет прорабатывать множество процессов последовательно или одновременно, что существенно улучшает бизнес-процессы в компании.
Постоянное совершенствование характеризуется:
- непрерывностью изменений;
- постепенной работой
- командным подходом;
- охватом всего предприятия;
- принципом бездефектности (работа на опережение).
Таким образом, удается контролировать и постоянно улучшать текущие бизнес-процессы в компании, не прибегая к глобальным изменениям.
Схема бизнес-процессов
При выборе графического формата составляется схема, которая демонстрирует весь его механизм. Строят ее чаще с применением специальных программ, но черновой вариант можно создать и вручную.
Схема строится в 9 этапов:
- Фиксируем границы – начальную и завершающую точки процесса.
- Отображаем основные блоки – каждый блок соответствует этапу цикла и располагается в соответствии со своим местом в цепочке.
- Добавляем ответвления – важно отобразить все возможные пути развития событий.
- Распределяем роли – схема не включает имена и должности участников бизнес-процесса, вместо этого работникам присваиваются роли. Один участник может иметь две и более ролей в структуре.
- Добавляем документы – это может быть любая важная для бизнеса информация (проект, презентации, доклады, кейсы, инструкции, электронные письма и т. д.).
- Указываем ПО и источники данных – схема должна содержать сведенья обо всех программах, используемых для автоматизации бизнес-процесса.
- Включаем материалы и инструменты – все то, что помогает в успешном достижении намеченной цели.
- Вносим ключевые показатели эффективности – критерии, которыми будут пользоваться сотрудники управления при оценке результативности персонала.
- Моделируем бизнес-процесс, используя все перечисленные сведенья.
Схему можно отобразить в виде карты или маршрута с применением стандартных международных форм документирования (нотаций).
Карта имеет вид блок-схемы, в которой по вертикали в столбцах обозначаются участники процесса, а в строках по горизонтали – интервалы времени. Такая форма изображения помогает проследить, как информация передается между подразделениями. Слишком сложная карта является поводом оптимизировать бизнес-процессы.
Маршрут представляет собой схему движения информации и ресурсов в ходе бизнес-процесса. Применяется для демонстрации параллельных действий при участии в процессе разных структурных подразделений. Детализировать маршрут сложно.
Управление бизнес-процессами
Работа с бизнес-процессами в компании невозможна без управления, в противном случае не удастся эффективно реализовать ее потенциал и достичь успеха.
Управление бизнес-процессами (BMP) предполагает системный подход к проведению мероприятий по их оптимизации, повышению точности и скорости выполнения. Такое управление может осуществляться неавтоматизированным путем или включать автоматизированные средства.
Можно выделить 4 этапа BPM, прохождение каждого из которых находится под чутким управлением менеджера.
- Моделирование. Предполагает выявление и описание бизнес-процессов с разграничением зон ответственности лиц, на которых возложено управление.
- Исполнение. Работники выполняют свои обязанности в соответствии с поставленными задачами.
- Контроль. Действия подчиненных строго контролируются, ежедневно отслеживается выполнение плана. На основании этих данных руководство может принять решение о поощрении персонала, штрафах, возмещении дополнительных расходов.
- Улучшение. Анализируется результат бизнес-процесса, выявляются ошибки, слабые стороны. На базе этого проводится оптимизация для улучшения результатов в следующих циклах.
Грамотное управление бизнес-процессами на предприятии – залог правильно поставленных задач и хороших результатов.
Итоги
Мы понимаем, что находимся в самом начале пути. Например, ещё не описаны все вспомогательные процессы — и я молчу про управленческие. Но уже сейчас мы ощущаем положительные изменения в сторону интенсивного роста:
- Мы стали более осмысленно подходить к системе мотивации сотрудников, так как знаем, к каким показателям нужно её привязывать, чтобы увеличить общую эффективность бизнеса.
- Уменьшили отток клиентов на техподдержке. В последнем квартале он фактически отрицательный. Как следствие, вырос LTV.
- Усилив отдельные этапы процесса, мы увеличили рентабельность проекта. Одним из самых убыточных этапов в разработке проекта был дизайн: нам не всегда удавалось попасть в ожидания клиента и не находилось достаточно аргументов для защиты идей. Внедрили более глубокую аналитику (маркетинговый бриф, анализ целевых персон, анализ статистики систем аналитики, конкурентный анализ и так далее) внедрили чек-листы и мудборды для понимания предпочтений клиента (из серии «шрифт с засечками или нет»). Обговариваем с клиентом условия презентации дизайна. Показываем дизайн только узкой рабочей группе клиента, которая участвует в проекте с самого начала и знает всю историю коммуникаций.
- Улучшили взаимодействие между отделами — к примеру, ввели регламенты передачи проекта. Так менеджер по продажам не получит вознаграждение, пока не передаст проект в соответствии с регламентом, которой описан в задаче передачи проекта.
- Повысилась вовлечённость команды в развитие компании. К слову говоря, в новой рабочей группе по второму основному процессу присоединились новые участники. Большинству в принципе стало не всё равно, как только пришло понимание, что у них появилась возможность качественно улучшить процессы, в которых они принимают ежедневное участие.
- Поднялся командный дух. Совместная работа над улучшением процессов лучше любого корпоратива с пивом и пейнтболом.
#Колонка