6a00d83451c8df69e201348646310b970c-800wi

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

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

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

На мой взгляд моделирование процессов в BPM системах, в большинстве случаев также приводит к провалам проектов. Редко где их применение хотя бы не вредит. И совсем редкость — применение с пользой. Но сейчас чуть о другом…

Есть много статей на тему case management, а также его разновидности adaptiva case managment и его отличия от популярных принципов BPM-подхода.

Сегодня хотелось бы поднять тему принципа неопределенности задачи.

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

В этой части есть две интересные особенности:

1. то что такое «неопределенность»

2. и то, какой инструмент дается в кейс-менеджменте для устранения этой неопределенности в любых масштабах

Что такое неопределенность?

Давайте дадим точное определение термина «неопределенность» (прошу прощения за вынужденную полутафталогию):

НЕОПРЕДЕЛЕННОСТЬ в системе [systems uncertainty] — ситуация, когда полностью или частично отсутствует информация о возможных состояниях системы и внешней среды. Иначе говоря, когда в системе возможны те или иные непредсказуемые события (вероятностные характеристики которых не существуют или неизвестны). Это неизбежный спутник больших (сложных) систем; чем сложнее система, тем большее значение приобретает фактор неопределенности в ее поведении (развитии).

Какие способы борьбы существуют с ней? По сути только один… это исследование. Давайте дадим определение и этому термину:

Исследование (буквально «следование изнутри») в предельно широком смысле — поиск новых знаний или систематическое расследование с целью установления фактов. В более узком смысле исследование —научный метод (процесс) изучения чего-либо[1].

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

Банально? Да. Но в это и суть кейс-менеджмента.

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

Примеры:

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

2. а вот кейс «выдать справку о доходах». Что тут может быть неопределенного? Да по сути мало чего, тут все максимально понятно в 99% случаев. Но может быть 1% случаев, где возникнет всплеск степени неопределенности: если выдавать справку стал человек который раньше этого не делал или если справка будет запрошена для редкого банка, у которого свои заморочки с оформлением.

По степени неопределенности, задачи удобно делить на 3 типа: мозги, седина и процедуры (по классификации Д. Майстера, детально эти типы расписаны тут).

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

Можно сказать что минимальная степень неопределенности есть даже в самой простой задаче. И этап исследования там может принимать одну из двух форм:

1. пойти и подергать другого сотрудника вопросами

2. прочитать инструкцию по процедуре

Если п.2 выполнен плохо, то вся нагрузка падает на п.1 — в малых объемах это не проблема, но с ростом организации этот пункт начинает вызывать большие проблемы.

Процедуры, это важный элемент системы. Особенно если мы говорим о процессе, в котором циркулируют задачи типа «процедуры».

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

Идем далее…

Ключевой метод кейс-менеджмента

Какие универсальные методы есть для борьбы с любыми типами неопределенностей, в любых типах задач (кейсов)?

Это контрольные списки (check lists, чек-листы).

Понятно что эта идея взята из GTD, но во многих современных системах для решения задач, этот механизм успешно применяется.

Чтобы понять важность контрольного списка для повышения эффективности задач, приведу ряд примеров:

1. Большой проект, на год с лишним, внедрение системы электронного документооборота, где есть этап интеграции с 1С. Тип «Мозги». Все хорошо, но когда подошли к этапу разработки модуля и запуска, обнаружили что этап интеграции выполнен, а результата нет. Интеграция не крутится. Почему так произошло? Да потому что было большое и сложное ТЗ на 100 листов, а вот простого списка условия приемки на пол листочка не было. Практика показывает что список на пол листочка в большинстве случаев работает лучше чем ТЗ на 100 листов.

2. Очень простая задача типа приема сотрудника, с регистрацией в информационной системе. Тип «Процедура». Что включает в себя регистрация в информационной системе? В инструкции это все прописано, но как добиться того чтобы сотрудники занятые на этой должности, всегда следовали инструкции и не пропускали там ничего? Снова чек-лист. Делаем его и сотрудник даже если никогда не выполнял эту процедуру, увидев список условий, которые нужно выполнить для закрытия задачи, заглянет в инструкцию. Проверено на практике.

3. Ставим задачи программисту. Это задача типа «Седина». Прописываем ТЗ на 2 страницы, но решаем добавить чек-лист. Пишем чек-лист и волшебный феномен структурирования вызывает спазм головного мозга, вспоминаем что в ТЗ забыли добавить какой-то раздел. Добавляем. И это только одно преимущество. Когда специалист берется за задачу, он уже видит пошаговую схему. Тут включается другой феномен струкутрирования. Концентрировать внимание со списком и без — это небо и земля. Со списком концентрация многократно выше, когда ты видишь шаги, и можешь их отмечать галочками. Этот феномен расписывается в GTD. Тут на нем останавливаться не будем. Ни одно ТЗ не дает такого прироста в эффективности как чек-лист.

Тоже самое чуть иначе было описано тут.

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

Итого

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

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

И еще одна важная особенность. Степень неопределенности, это величина зависимая не только от задачи, но и от исполнителя. Если мы ставим на задачу исполнителя, у которого низкий уровень знаний по существу задачи, то степень неопределенности подскочит. Решить ее будет сложнее. Это может привести к провалу.

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

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

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

Реальное знание можно получить только в результате практического действия (с) Конфуций