XRM и Теория ограничений

Элия Голдратт создал весьма впечатляющий инструмент управления. Его "Теория ограничений" не только убедительна, благодаря тому, что она опирается исключительно на здравый смысл и логическом построении "если/то". Она весьма проста в применении. Нужно только найти ключевое ограничение системы, предпринять меры для его устранения или частичной компенсации (на самом деле у Голдратта этот шаг состоит из трех: оптимизация в точке ограничения, перестройка всей системы с учетом действующего ограничения, устранение ограничения, но если без дополнительных затрат вы можете сразу сделать найденное ограничение меньшим, чем следующее по значимости, то не вижу причин этого не делать) и пожиная плоды этих незамысловатых действий вернуться к поиску следующего ключевого ограничения.
Все хорошо для классического производства, например, завода. Как только дело касается организаций сферы обслуживания или, например, исследовательских организаций, все становится существенно сложнее. Сам Голдратт говорит, что описанная им в книге "Цель. Процесс непрерывного улучшения" процедура применения Теории ограничений является частным случаем применения Мыслительных процессов, которые для организаций других профилей должны использоваться с нуля, как наиболее общий подход.
Все кто читал "Дело не в везенье" (в русском переводе "Цель-2") и пробовал применить Мыслительные процессы на практике хорошо знает, что дело это довольно сложное. Вам не только понадобится несколько мотивированных участников с развитыми навыками логического мышления и хорошо знакомых с темой, что само по себе - уже не слабое требование. Еще потребуется много времени и не детские интеллектуальные усилия. Желательно на фоне отсутствия психологических проблем, в духе несовместимости участников рабочей группы.
Не претендуя на изобретение серебряной пули, посмотрим как имея современные технологии этот процесс можно было бы упростить. Хотя бы частично и хотя бы в некоторых случаях.
Итак, у нас есть XRM - система которая соединяет всех участников предприятия отношениями типа "заказал/взял в работу" и "предоставил результат/принял". Причем этими же связями организация соединена со своими клиентами и поставщиками. Благодаря этому, для любого запроса инициированного клиентом, можно построить цепочку реакции. В идеале это должна быть петля, которая проникая через всю организацию затрагивает поставщиков (которые могут быть и внутренними) и возвращается к клиенту в виде адекватного удовлетворения его запроса. Кстати, под адекватным удовлетворением должно понимать не формально-зеркальную реакцию в духе "вопрос/ответ на вопрос". Если за вопросом стоит не чистое любопытство, а какая-либо потребность (а это верно в абсолютном большинстве случаев), то ответом на вопрос должна быть реакция удовлетворяющая эту потребность. Если говорить о коммерческих организациях, то скорее всего, это продажа.
Если процесс построен на базе XRM, то мы с приемлемой степенью обобщения можем сформулировать цель и необходимые условия ее достижения. Они окажутся очень похожими на то, что предлагает Голдратт для компаний c публичным акционерным капиталом, но в более точечном виде для рынка и более широком для работников.
Цель: зарабатывать деньги сейчас и в будущем.
Первое необходимое условие: удовлетворить сейчас и в будущем запрос каждого клиента, чьи потребности находятся в рамках бизнес-процессов компании.
Второе необходимое условие: обеспечить сейчас и в будущем комфортные условия для каждого вовлеченного сотрудника или контрагента.
Для начала находим петли реакции. Сделать средствами XRM это весьма просто, т.к. это часть базовой функциональности напрямую вытекающая из идеологии. Если петля сложная - содержит ветви - это ничего не меняет, потому что в любом случае все они должны влиться в основную петлю, которая замыкается на клиенте. В противном случае ветвь является избыточной и должна быть отсечена.
Теперь мы можем классифицировать петли. На самом деле, достаточно их разбить всего на две группы: эффективные и неэффективные. Т.е. удовлетворяющие поставленной цели с обеспечением необходимых условий и не удовлетворяющие/не обеспечивающие. Сделать это чуть сложнее, но высшая математика и магические трюки не понадобятся. К неэффективным петлям нужно отнести все, которые не закончились продажей, или вызвали негативную реакцию клиента (кроме крайних случаев, когда клиент свое неудовлетворение выказывает явным образом, отсутствие удовлетворенности можно идентифицировать по отсутствию повторных покупок), или привели к ущербу для комфорта вовлеченных сторон (овертаймы, конфликты, изменение регламенты поставки и т.д.). Соответственно, эффективные петли - все остальные. В этой методике есть технические нюансы, связанные со сбором информации и ее правильной интерпретацией. Но ничего такого, чтобы выходило за пределы охвата XRM.
Теперь мы берем совокупность неэффективных петель и получаем статистику по проблемным узлам. То, что при другом рассмотрении является проблемой, при таком подходе становится преимуществом. Сложные системы порождают разнообразные петли и их пересечение позволяет найти проблемные узлы легче, чем при анализе отдельных цепочек.
Дальше все решается количественными методами. Тут уже есть некоторое количество математики, но так как такой подход не опирается на элементы специфичные для какой-либо отрасли, то достаточно единожды разработать данные алгоритмы, чтобы использовать их для любой организации. Важно, что такая диагностика позволит не только найти проблемные узлы, но и выделить природу его ограниченности. Что позволит легко использовать классические инструменты менеджмента для устранения ограничивающего фактора или снижения его влияния. Собственно, эту задачу тоже можно решить с опорой на XRM, но об этом - в другой раз.