Как процессы разомкнутого цикла нарушают поток информации в бизнесе

За свою карьеру я довольно много раз перепроектировал бизнес-процессы, и самая большая проблема, которую я нахожу, всегда одна и та же: незамкнутые бизнес-процессы. Процессы без обратной связи возникают в основном потому, что ответственность распределяется между несколькими людьми и часто между несколькими отделами. Информационный поток, который начинается в НИОКР с запроса на новую единицу оборудования, может пройти через отдел финансов и закупок, прежде чем выйти за организационные границы к поставщику (где он будет проходить через несколько отделов по очереди), а затем, в конечном итоге, вернуться к приему и отделу. , если повезет, группа R&D, которая инициировала поток.

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

Открытые циклы могут стоить миллионы долларов

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

Односторонняя связь между зонами ответственности

Как и во всех крупных организациях, обязанности были разрозненны. Кому-то на производстве нужно оборудование X, поэтому он информирует об этом финансовый отдел, и создается заказ на поставку (PO). Заказ отправляет заказ на покупку поставщику. До года в будущем X доставляется и принимается Получателем. Получение уведомлений Производство и Финансы. Финансовый отдел выпускает бирку актива, которая прикрепляется к X. X помещается в производственную линию, и все в порядке.

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

Давайте предположим, что X представляет собой сложное оборудование, возможно, линию наполнения и отделки. Он состоит из 20 основных компонентов, каждый из которых будет заменяться несколько раз в течение срока службы. Тег актива, случайно нанесенный на одну часть X, исчезнет из-за износа. Что еще хуже, тег актива может даже не применяться, потому что он не доходит до получения вовремя. После этого никто понятия не имеет, как отслеживать X, и, следовательно, не знает, как вывести его из эксплуатации в конце срока службы. С налоговой точки зрения X по-прежнему является действующим объектом налогообложения.

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

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

Создание двусторонних информационных потоков

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

Шаг первый

Производству нужно X, поэтому они просят финансовый отдел открыть заказ на покупку. Финансовый отдел теперь сверяется с производством для подтверждения, предоставляя подробную информацию о предыдущих заказах на X за 24 месяца. Случайное дублирование заказов исключено.

Шаг второй

Производство предоставляет финансовому отделу информацию о компонентах X, которые будут заменены в течение срока службы. Финансовый отдел создает теги активов для каждого компонента и подтверждает их с Производством. Оба модуля ERP заполнены соответствующими тегами активов для каждого компонента, что позволяет отслеживать жизненный цикл активов.

Шаг третий

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

Шаг четвертый

Каждый раз, когда компонент заменяется, Производство информирует Финансовый отдел, и новый тег актива для этого компонента создается и размещается на новом компоненте Производством, а затем подтверждается в обоих модулях ERP. Затем финансовый отдел начинает процесс удаления старого компонента из бухгалтерского учета, в то время как производство проходит процесс вывода из эксплуатации в соответствии с Руководством по эффективной практике (GMP). По окончании вывода из эксплуатации производственный отдел информирует финансовый отдел, чтобы актив можно было снять с бухгалтерского учета.

Детали немного сложнее, чем в этом упрощенном примере, но суть ясна: на каждом этапе пути есть явные проверки и подтверждения.

Обеспечение действий в непредвиденных обстоятельствах

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

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

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

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

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

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

Подтвердить ключевые события

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

Например, когда клиент отправлял пакет документов, теперь он отправлял электронное письмо менеджеру по работе с клиентами, информируя об этом. Менеджер по работе с клиентами передаст это ответственной стороне в обработке требований. Если документы не будут получены в течение трех дней, будет объявлено предупреждение. Когда документы были получены, клиенту пришло электронное письмо с подтверждением получения. Обратное также было верно, когда компания отправляла обработанные документы обратно клиенту.

Поскольку большинство клиентов использовали почту США для перетасовки печатных документов туда и обратно, процессы с обратной связью, использующие явные проверки на каждом этапе, означали, что любые потерянные документы можно было быстро идентифицировать и принять меры для исправления ситуации.

Разработка процедур обработки исключений

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

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

Теперь у постдока также есть автоматическое уведомление в календаре, чтобы проверить в Финансах, если они не получат подтверждение о возбуждении заказа на покупку в течение установленного периода времени. Когда финансовый отдел создает заказ на покупку, постдок получает электронное письмо с подтверждением того, что оно было отправлено поставщику, и постдок пересылает это подтверждение PI.

На этом этапе либо PI, либо пост-доктор устанавливает другое автоматическое уведомление календаря, чтобы гарантировать, что, если ничего не будет получено от поставщика в течение установленного периода времени, кто-то сверится с поставщиком, чтобы гарантировать получение заказа на поставку и отправку заказа. оборудование, которое было заказано.

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

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

Учимся создавать замкнутые процессы из SQL

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