Ключевые моменты Case Management

По статье Хенка де Мана Case Management: A Review of Modeling Approaches

Хенк де Ман, research director компании Corsys, выделил следующие особенности case management (далее CM):
1. Центральное место в управлении кейсами занимает непосредственно кейс. Так в здравоохранении, из которого проистекает направление СМ, «история болезни» пациента накапливает всю необходимую информацию и определяет дальнейшие действия терапевта.
2. CM предполагает сотрудничество и коммуникацию. Кроме того, участникам обработки кейса придется реагировать на новые события
3. Как правило, действия сотрудников обслуживающих кейс, строго не предопределены. Эксперту понятно, что необходимо сделать в текущей ситуации, а дальнейшие действия вытекают из результатов первого шага.
4. Цель является более ясной, чем путь её достижения. Для достижения цели возможны различные пути. Выбор того или иного конкретного пути будет определяться в ходе достижения цели, а не планироваться заранее.
5. Исполнитель кейса – это эксперт (knowledge worker), владеющий навыками, которые позволяют ему иметь определенную свободу в принятии решения, в рамках зоны своей ответственности.

Что интересно в этих характеристиках. Во-первых, произнеся слова сотрудничество, коммуникация, сбор информации и knowledge worker мы моментально попадаем на территорию социального ПО, т.е. для корпораций – область Enterprise 2.0. Во-вторых, мы не расстаемся с такими понятиями как роли, активности, последовательность действий и пр., т.е. продолжаем пребывать на территории BPM. Одним словом, нас ожидает микс наиболее узнаваемых ИТ идей текущего момента social software и BPM

Продолжение: Case management и модели процессов

Ключевые моменты Case Management: 6 комментариев

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

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

    Наверное, можно и дальше проводить сравнение, но думаю что приведенных выше моментов достаточно для иллюстрации различий

  2. Любопытно, но, мне кажется различия не столь очевидны. “Теоретически, теория и практика – одно и тоже, однако на практике это не так”
    1. Временные ограничения. Здесь явное недоразумение. О сроках в определении ни слова. Как учит нас PMBOK: “Термин “временное” означает, что у любого проекта есть четкое начало и четкое завершение. Завершение наступает, когда достигнуты цели проекта; или осознано, что цели проекта не будут или не могут быть достигнуты; или исчезла необходимость в проекте, и он прекращается.” Кроме того, в реальной практике мы всегда имеем дело с определенным целеполаганием и сроками достижения целей. Например, в медицинской практике, откуда, как я понимаю, и начался case management, обслуживание больного – цепь проектов, состоящих, например в подборе технологии лечения. Лечащий врач всегда определяет определнные временные границы, за пределами которых принмается решение о дальнейшем лечении. Это обусловлено очевидными биологическими причинами, или хотя бы интересами страховых компаний. Таким образом, мы сталкиваемся с цепочкой проектов. Можно, конечно, назвать ее кейсом, но это не дает ничего нового.
    2. Об изменении способов достижения из PMBOK “По мере того как выявляются и осознаются новые характеристики и информация, касающиеся проекта, могут возникнуть необходимость в доработках. Значительные изменения, происходящие во время жизненного цикла проекта, приводят к необходимости пересмотреть один или несколько процессов планирования и, возможно, некоторые из процессов инициации.” Есть еще управление рисками.
    3. О накоплении опыта. Например, опять же в PMBOK: “Документация о накопленных знаниях. Все накопленные знания, приобретенные во время проекта, должны быть оформлены в виде документов для того, чтобы они стали частью исторической базы данных организации….” Далее идут весьма конкретные указания. Вообще “Наличие повторяющихся элементов не нарушает принципиальной уникальности каждого проекта”.

  3. РМВОК стоит один раз прочитать, чтобы знать терминологию и знать врага в лицо:).

    Риски стимулируют изменения, изменения создают риски – таким образом, имеется порочный круг и попытки централизованного управления рисками в стиле РМВОК, создают достаточно большой, зачастую бесмысленный оверхед выполнения всего проекта, который всегда недостаточный, чтобы выполнить все функционально-ресурсные требования заложенные вначале. Как много ИТ стартапов с хорошим профитом результата выполнено по РМВОК без провалов за последние года два?

    Очевидно, что всякие agile подходы как раз пытаются не предсказывать и как-то управлять рисками, а изнчально используют процесс ориентированный на неопределенность, которая структурируется за счет синергии комьюнити участников (не путать с иерархией) и понимания того, что никогда никакая документация (которая в принципе почти всегда содержит только 20% информации из того, что нужно реально в работе) и стек руководства (где обычно на каждом уровне свои интересы, перпендикулярные целям проекта) не смогут обеспечить выпуск проекта и его поддержку в будущем. Именно коллективная, слабостуктурированная и итеративная работа стимулирует выбор именно правильных путей решения задач – сроки и план проекта от рм и архитектора/ГИП могут быть только ориентирами и видениями не редко далекими от реальности, сам процесс проведения проекта по agile позволяет всем лучше понять, что вообще хочется получить в результате.

    Когда менеджеры начинают понимать роль неопределенности, они начинают выстраивать и операционную деятельность на agile-подобных принципах: тогда и появляется социальные корп-сети, АСМ и т.п. – дополняющие гибкую проектную деятельность компании.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *