Функциональный подход к анализу процессов

Давайте поговорим об одном из немногочисленных "языков" использующихся для анализа проблемы и постановки задачи. 

Речь пойдет об VA или ФСА. Но мы не будем рассматривать его в разрезе выделения функций в железном продукте. Про это написано достаточное количество хороших книг (хотя если хотите что можно и про это поговорить, дайте знать). 

Мы поговорим о том чем он может нам помочь в отношении процессов. 

Процесс, как и работа вообще, совершается для чего-то, ради какой-то цели. Доставить товар, произвести леденец, сделать прическу, принять решение, починить прибор и пр. 

Как ни странно достичь ее, реализовать ее достижение можно разными способами. 

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

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

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

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

Поэтому данную задачу обычно не рекомендуется отдавать людям которые не участвуют в процессе. 

Нам надо сформулировать цель (она же функция) процесса: связкой глагол + существительное.

Далее ответить на вопросы: 

1. кому это надо? = с внешним клиентом все очевидно. 

2. для чего? (зачем?; почему?) = поднимаемся на уровень выше. 

Это звучит сложно, но покажем на примере:

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

В эту машину которая поедет по объектам (завозить расходники и оборудование) положили прибор (водителю сказали и написали для какого это объекта).

Важно! данный прибор отличался от типового который обычно используется.

Что случилось далее: водитель приехал на объект к человеку который заказывал прибор. Человек увидел что прибор Не тот который был у него и не стал его забирать. Водитель повез прибор обратно. Ну а потом снова повез куда где заказывали.

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

В чем цель процесса? Зачем / для чего это?

Здесь мы бы ее сформулировали следующим образом "Обеспечение непрерывность измерений" (вопрос к вам а в каких еще примерах она звучала бы так же?). 

Нам оно надо или нет? А клиенту/заказчику?

В данном случае заказчик именно за это платит.

Вы можете спросить почему именно так? Если мы везем оборудование значит задача из области логистики, мы же везем датчик на замену, значит цель "Заменить датчик" или "Доставить датчик". 

Но тут мы поступаем хитро и спрашиваем: "А для чего мы везем датчик?" 

Не для того же чтобы просто привести, мы его везем для того чтобы заменить не работающий, опять "А для чего?". 

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

А вот доставка со склада нового датчика в случае его замены это уже конкретная реализация решения задачи (которое в свою очередь порождает новую задача его оптимально реализации). То есть здесь мы стараемся сформулировать функции так чтобы сама формулировка наталкивала нас иные варианты решения. Для этого мы можем на более высокий или более низкий системные уровни = к надфукции или подфункции, а так же группировать функции или дробить их для нахождения уровня постановки задачи. 

🎛 Основаная функция: Измерение => Датчик; Да конечно можно пойти еще выше в область "для чего мы измеряем", но в данном случае нам хватит этого.

🎛 Вспомогательная функция: Непрерывность измерения => РАЗНЫЕ РЕАЛИЗАЦИИ => Процесс доставки датчика с базы (одна конкретная реализация);

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

Каковы характеристики функции? От чего мы отталкиваемся при подборе?

В данном случае основной характеристикой будет "время отсутствия измерений датчика". 

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

Иногда узнать это достаточно просто (это прописано в договоре с клиентом в виде штрафа), а иногда достаточно сложно: как отреагирует потребитель на плохую работу или отсутствие той или иной функции.

В такой постановке вопроса мы приходим к иным вариантам решения задачи, отвечаем на ОБРАТНЫЙ ВОПРОС (к вопросу "для чего?") КАК? мы можем обеспечить "непрерывность измерений?": 

1. Сделать так чтобы датчик не ломался или ломался меньше (тогда и возить будут не надо или надо будет это делать не так часто). Тут можно даже думать в сторону замены типа датчика на иной, нам же в конце концов надо измерять параметр, а делать это можно разными способами...

2. Создать механизм заблаговременного обнаружения того что датчик скоро сломается. Тогда мы сможем заранее расчитывать что, куда и когда надо вести.

3. Держать запасной датчик на месте. 

4. Держать запасной датчик неподалеку, например если у нас есть несколько близко расположенных обьектов в отдалении от склада может иметь смысл держать не по одному запасному на каждом, а например по одному на 5, 10 или иное количество обьектов 

5. Держать запасной датчик на ближайшей производственной базе. Такой вариант и реализуется.

Это можно схематично изобразить следующим образом:

Работает достаточно простой механизм:

Как? ==>  <== Для чего?

Спрашивая "Для чего?" мы абстрагируем. Спрашивая "Как?" мы стараемся получить пучок вариантов и выбрать из них какой-то конкретный. Это работает и на отдельно взятом процессе. 

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

Или ваш процесс настолько типовой что на рынке уже есть устоявшаяся лучшая практика. 

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

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

Все эти варианты (предложенные выше) тоже могут выступать решением задачи. 

Далее необходимо сравнивать затраты на конкретную реализацию и на невыполнение функции.

Заметьте что процесс мы пока даже не трогали, а уже тем более не трогали отдельного работника.

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

Это как раз следующий вопрос "Для чего?" от "Измерение". Для чего мы Измеряем? 

Например для того чтобы "Определить мощность продуктивного пласта в процессе бурения". 

С такой постановкой вопроса мы можем выйти на иные решения. Как еще ее можно выявить?

Возможно есть: 

1. Иные параметры которые можно измерять? 

2. Иной способ измерения?

3. Иной датчик, но с этим же способом измерения (более надежный, более точный, более дешевый)?

Ну и конечно можно пойти еще выше и спросить "А для чего нам определять мощность продуктивного пласта в процессе бурения?" 

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

Ну и конечно один из разделов / аспектов базы знаний консультанта по ФА или бизнес-процессов это знать типовые функции компании (на том или ином рынке) и собирать новых способы их реализации.

Можно долго оптимизировать процесс фрезерования, хотя иногда эффективнее просто перейти про процесс штамповки деталей.