Ключевые моменты 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 и модели процессов

Реклама

6 responses to “Ключевые моменты Case Management

  • Константин Поляков

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

  • Maxim Smirnov

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

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

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

  • Константин Поляков

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

  • Слава

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

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

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

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

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

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s