Кейс-менеджмент: долго, дорого, плохо?

Пару дней назад на cnews появилась заметка Чем выделяется кейс-менеджмент? Мне трудно сказать поможет ли эта статья погрузится в тему неподготовленному читателю. Наверное, перевод работы Forrester «Dynamic Case Management — An Old Idea Catches New Fire» или других экспертных статей был бы более уместен. Но есть в заметке cnews одна фраза, вызвавшая у меня просто детский восторг:

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

Вообще-то, я считал, что рынок ECM решений умирает. Идея Enterprise Content Management (именно идея) хороша, а лет 10 назад была просто инновационна. По сути своей, ECM отвергает две предшествующие ей идеи, а именно идею электронного документооборота и идею создания отдельной новой системы для каждой предметной области. Недостатком электронных документов является их непрозрачность. Т.е. у нас нет способа автоматизированной обработки содержащейся в документе информации. Внешне, все документы одинаковы. Мы не можем определить, что в нем лежит иначе как, позвав человека и попросив его прочитать документ. Альтернативная идея заключается в хранении структурированных данных в реляционной базе данных. Проблема в том, разработка баз данных оправдана в случае большого числа однотипных данных. Нет смысла городить систему для хранения одной записи. ECM объединяет подходы. Простейший пример ECM решений – картотека документов, практически как в библиотеке. Т.е. вы вытаскиваете из документа некоторую информацию, ключевые поля и заносите их в реляционную базу данных. Можно сортировать, группировать, искать и т.п. Возьмите хорошего ИТшника и он за пару дней построит вам систему из базы данных для хранения карточек и версионного хранилища файлов.

Однако современные ECM системы за время своей жизни обросли огромным количеством абсолютно ненужных модулей, начиная от систем распознавания отсканированных документов и заканчивая поддержкой стандарта CMIS. Тащить эти атавизмы в будущее? Нет. Слишком дорого. С другой стороны, многие из них игнорируют принципы интернет приложений, такие как идентификация контента посредством перманентных гиперссылок, простые глаголы REST и т.д. Упомянутый выше CMIS поддерживает привязку к web-сервисам, но не согласован с протоколом WebDAV. Продолжать можно до бесконечности.

Неужели ACM способен реанимировать этих динозавтров? Посмотрим…

Кейс-менеджмент: долго, дорого, плохо?: 15 комментариев

  1. В статье есть и еще фразы, из-за которых к остальному тексту статьи относишься уже с подозрением, например: “Это касается и кейс-менеджмента – нового термина сегмента СЭД”. Но подозрение, возникающее из-за отдельных фраз, само по себе неплохо, оно помогает не терять оптимизма, читая всякое. Например, после фразы Макса Пучера “Adaptive does not suppose collaboration” возникшее подозрение помогло пережить дальнейшие его пассажи о “смерти ACM” 🙂

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

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

      1. Судя по остроте дискуссий вроде нет пока никаких изначальных требований в силу того, что само понятие не устоялось, даже аббревиатура плавает в широком диапазоне от Adaptive Case Management до Dynamic Case Management. К тому же на самом деле требование простое и естественное, но тут очень важна реализация – то ли задавать метаданные, характеризующие структуру данных для кейса отдельно в описании (типа как в BPM делается), тем самым теряя преимущество простоты и адаптивности, то ли все это хранить в самом кейсе, решая задачу простого аттача данных вместе с описанием к кейсу и дальнейшего поиска по таким разнородным данным. А с реализацией, я вижу, возможны проблемы из-за необходимости хранить разнородные данные в одном пространстве кейсов
        ACM, все-таки, меньше идеология (в отличие от BPM), и больше технология и тут важна реализация

        Посмотрите, как похожи, по крайней мере внешне, системы BPM с их следованием стандартам BPMN и как различаются все системы ACM

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

  3. аааа! я кажется понял что такое ACM ))

    1. Все процессы организации условно можно разделить на однообразные-простые и уникальные-сложные.
    2. В книге Д.Майстера “Управление фирмой оказывающей профессиональные услуги” первые тип процесса называется процессом с малым рычагом управления, а второй с большим рычагом управления. Есть конечно и усредненные варианты.
    2.1. В первом случае можно загружать много людей с низкими компетенциями и компьютеры, они относительно легко поддаются описанию, один руководитель может справится с множеством операций и подвести под себя много сотрудников, без особых отлокнений от качества. Условно назовем это функциями (много простых, часто повторяющихся операций)
    2.2. Во втором случае, требуется больше людей с мощными компетенциями, компьютеры тут уже мало дают толку, больше зависимость от компетенций человека, его знаний и умения находить правильные решения, руководство здесь требует уже больше внимания к деталям и один руководитель может удержать уже меньшее число людей в подчинении без вреда для качества. Условно этот вид деятельности мы можем назвать проектами (мало сложных, уникальных или редко повторяющихся операций)

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

    Обычно этот тип операций называют Проекты, но в ITSM это названо Релиз (плохо переведенное слово release что в русском языке больше подходит к слову Реализация), а в купе с процессом управления изменениями, это называется Реализация изменений, если чуть проще то Управление проектом, а если совсем по русски, то Выполнение Технического Задания.

    Я ничего не упустил? 🙂

    1. Но если так, то мне нужно понять… а что подразумевается под инструментами ACM?
      Я сейчас использую GTD как инструкцию и Мегаплан как инструмент.
      С точки зрения движения из п.А в п.Б при реализации изменения (управления проектом, выполнения ТЗ) вроде как ничего и не надо. Кроме того что по ходу действия, для достижения результата под руку идут все средства, от систем бизнес анализа, до техники обольщения секретаршь и сотрудниц стратегически важных постов )

    2. Релизы – отличный пример. А вот относительно проектов у меня есть некоторые сомнения. Понятие project management очень популярное и толкуют его разные специалисты по-разному. Для финансиста проект – это, прежде всего инвестиционный проект, т.е. мероприятие по размещению денег с целью получения прибыли. В капитальном строительстве своя специфика. Появившееся у строителей понятие типовой проект вряд ли нравится апологетам классического проектного менеджмента 🙂 . Есть разница между тем, что называют проектами в современной компании, где их ведется десятки одновременно, и классическим проектом из учебников по высадке человека на Луну. На мой взгляд, понятие проекта слишком широкое и проектный менеджмент создавалась в большей степени для того, чтоб решать задачи высадки на Луну, а не запуска новой линейки продуктов, внедрения информационной системы и т.д. Как раз эти мероприятия лучше проводить с использованием ACM.

      Вернемся к релизам. Несколько ключевых особенностей релизов, которые требуют адаптивного управления, т.е. ACM:
      1. Проектный менеджмент предписывает нам очень четко управлять scope-ом проекта. Vision/Scope фиксируется на самых первых этапах проекта, при его инициации. При формировании релиза у нас есть возможность быть достаточно гибкими, самим решать какие запросы на изменения и дефекты мы включаем релиз, определять дату закрытия scope и т.д. Как это отобразить в нотации бизнес-процессов BPMN и в диаграммах Ганта я не очень понимаю.
      2. Обычно релиз включает в себя изменения нескольких конфигурационных единиц. Часть работ, таких как согласование интерфейсов или интеграционное тестирование являются общими. Другая часть работ – доработка конкретной программы, закупка оборудования и др. достаточно автономны. При этом сами эти работы могут быть очень сложными (содержать много этапов), но достаточно типовыми. Держать их виде отдельных активностей в проектном плане неудобно, но и элементарными работами назвать тоже нельзя. Проблемы внутри таких активностей чреваты вылезанием задачи на критический путь. На процессы это больше похоже, но проектирование координации таких процессов (перерасходовали бюджет на сервера – подешевле купим рабочие станции) упражнение весьма утомительное.
      3. И наконец, в отличии от классических бизнес-процессов и традиционных проектов в управлении релизами присутствует достаточная вариативность: не успеваем купить железо, запустимся на имеющемся, но потом переедем на новое; не можем получить данные из мастер-системы, возьмем из копии, ну и т.д.

      А на вопрос про инструменты ACM пусть отвечают вендоры. Я уже боюсь представить что они намереваются нам предложить под этим лейблом

      1. Управление проектом – да, затертое понятие.
        И определение из Вики особо толку не дает.
        Но мне понравилось определение из книги GTD: проект это результат требующий более 2-х существенных действия для достижения.

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

        Если применять проектное управление, то не из этих ли этапов состоят проекты?

        Мне кажется что Проект, это просто более модный зарубежный синоним слова Задача.
        И что задача, что проект, это достаточно абстрактные понятия, включающие в себя множество конкретных вариантов. Будь то Релиз (ИТ-проект), Кейс, Инвестиционный проект, Строительный проект и т д

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

        Вообще за мои последние 2 года практики в части описания процесса, я с самого начала выделил этот процесс, назвав его управление релизами… т.к. начинал с организации поставщика услуг ИТ.
        И сразу обнаружил что этот процесс хорошо подходит для обработки сложных не стандартных операций или ситуаций.
        Потом до меня дошло что релиз это не русское слово, а если его перевести то получится Реализация, по смыслу очень близко подходяшее к Проекту (решение задачи). И переименовал процесс в Управление проектами. Разделив проекты во-первых по размеру: маленькие, средние, сложные, а во вторых по практикам: 1С, ECM, СМК, управление …

        Таким образом получил процесс, который на входе получает любую не стандартную (без технологии, без точных инструкций) задачу, а на выходе ожидаемый или близкий к ожиданиям результат.
        Причем вне зависимости от практики, будь то 1С, ECM или СМК, этапы решения оставались практически без изменения (описание их сути я и заметил в статье по ссылке). Но этапы, и правила добавлялись в зависимости от размера. На малых проектах, хоть по 1С, хоть по СМК применялись одни инструменты, а на крупных (тоже хоть по 1С, хоть по СМК) – другие. В одних задачах какие то этапы можно было исключить, в других это грозило проблемами или провалом.

  4. >>Вообще-то, я считал, что рынок ECM решений умирает.

    Странная мысль. Управлять корпоративным контентом больше не нужно? Или просто дело в том, что все эти legacy applications уже с трудом конкурируют с новыми web 2.0 приложениями, имеющими схожие функции, а “офейсбученный” народ жаждет привычного интерфейса и на работе тоже?

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

    Ну, видимо, на сегодня реальных альтернатив именно эти 2, грубо говоря, как в СЭД – или карточка документа или файл документа. Но проблема понятна, и разработчики уже над этим трудятся (всякие RSS и прочие xml-структуры). Идея в том, чтобы расширить понятие гиперссылки на данные, ввести в обиход понятия элементарных адресуемых структур данных, рекурсивно встраиваемых друг в друга и располагаемых где угодно – в тексте поля БД, файле, на web-странице

    Web 1.0 – static web
    Web 2.0 – interactive web
    Web 3.0 – structured web

    >> Однако современные ECM системы за время своей жизни обросли огромным количеством абсолютно ненужных модулей

    В общем да. Уже ощущаю потребность “сбросить старую кожу” с СЭД и полностью скомпоновать новую СЭД/ECM на полностью интегрированных между собой компонентах web 2.0 – управление задачами на ACM, управление процессами согласования документов на AJAX-BPM, файловое хранилище с web-доступом, распределенные иерархические справочники на адресуемых структурах данных. И все это доступно одно из другого по ссылкам

  5. Максим, просьба прорецензировать мою точку зрения на ACM. Как я понял эту технологию, с учетом ссылки из этого поста http://corp.cnews.ru/reviews/index.shtml?2011/04/04/434941

    Мне еще далеко до SOA и применения ACM при взаимодействии ПО. Я пробую применить эти принципы при взаимодействии людей.
    Вот тут описал свое видение описания процесса по принципам ACM на примере одной простой процедуры
    http://itau.ru/2011/05/21/printsipyi-acm-kak-sostavit-instruktsiyu-po-protsedure/

    Очень интересно мнение эксперта 🙂

    1. У Cordys (Henk de Man) были какие-то наработки по формальному описанию ACM процесса. На основании их OMG и сделало известное RFР: http://www.omg.org/cgi-bin/doc?bmi/2009-09-23 Насколько я помню, предлагалось выделять два этапа обработки кейса – подготовка и исполнение. В свою очередь, на этапе подготовки проводилась оценка и планирование.

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

      Вот, нашел презентацию на эту тему http://www.slideshare.net/jamet123/case-management-processes-203614

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

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