Case management: основные виды работ

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

1. OMG уже пыталось навести порядок в этом вопросе и даже готовило RFP Case Management Process Modeling http://www.omg.org/cgi-bin/doc?bmi/2009-09-23 Согласованного результата не получилось. На мой взгляд, порядок обработки кейса существенно зависит от предметной области. В документообороте подход будет один, при обработке заявок – другой, а при решении инцидентов третий. Однако, некоторая база присутствует в RFP и предшествующих ему документах .

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

Теперь про виды работ. Я проклассифицировал их следующим образом: предварительные, основные и вспомогательные.

Предварительные виды работ связаны с перехватом и регистрацией кейса. Они производятся однократно. Операции перехвата могут быть как очень простые (добавление заявки в базу), так и довольно сложные, включающие поиск дубликатов обращений, проверку их правомерности и т.д. Операция регистрации – это присвоение кейсу уникального идентификатора. Операция не такая безобидная, как это кажется на первый взгляд. Здесь очень важно не переусердствовать и не смешать операцию регистрации и классификации. Предположим мы получили заявку на предоставление сервиса от клиента X. Очень велик соблазн кроме уникального номера заявки включить в её идентификатор код клиента и код сервиса. Это ошибка. Завтра выяснится, что одни клиенты могут оформлять заявки по поручению других, заявка на предоставление сервиса – это попытка решить инцидент по уже предоставленному сервису и т.д. Одним словом идентификаторы типа «AБВ.123-ГД/22.05» не имеют право на существование.

Основные виды работ можно разделить на обогащение кейса, преобразование кейсов и планирование-реализацию-контроль. Обогащение заключается в связывание кейса с дополнительной информацией. В ходе этой деятельности мы привязываем к кейсу различные виды информации – документы, записи, неструктурированные данные. Частным случаем обогащения является классификация. Классификация – это такое обогащение кейса данными, когда информация берется из предварительно заполненных справочников: инициатор кейса из справочника клиентов, тип сервиса – из справочника сервисов и т.д. Адреса, даты, типы сервиса, группы клиентов… любая таксономия, которой мы располагаем. Обогащение – более общий случай классификации, т.к. при обогащении мы можем привязать к кейсу то, чего нет в наших справочниках. Еще один частный случай обогащения заключается в обращении за дополнительной информацией к клиенту. Назовем его уточнение. Уточнение может полностью или частично изменить достигнутые в ходе обработки кейса результаты. Клиент может просто прийти и закрыть кейс. Еще раз напомню, что все эти виды деятельности могут возникать в любой момент жизненного цикла кейса и повторяться произвольное число раз.

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

Ну и, пожалуй, главное, что происходит при обработке кейса это выполнение работ. Мне кажется, здесь вполне уместны активности из цикла Деминга: планирование, реализация и контроль. Не буду на этом долго останавливаться, упомяну лишь, что данные активности тесно связаны с другими двумя: выделение ресурсов и их изъятие. Выделение ресурсов это и назначение ответственного за кейс в целом (case manager) и назначение ответственных на отдельные задачи. Завершение кейса можно рассматривать как частный случай изъятия ресурсов. Справедливости ради следует сказать, завершается не сам кейс, а связанный с ним поток активностей. Т.е. после закрытия кейса, мы можем продолжать его использовать. Это происходит при объединении кейсов, при поступлении новых запросов того же вида сервиса или от того же клиента и, что самое главное, при анализе наших процессов с целью их улучшения.

Вспомогательные процессы: трекинг, эскалация, улучшение. С трекингом все более-менее просто. Все изменения кейса должны фиксироваться. Это обычно происходит автоматически. На основании трекинга осуществляется формирование статистики по процессам и мониторинг. Единственное на что хочется обратить внимание – любая протоколируемая операция должна быть осмысленной. Помните, как у Алистера Коберна: каждый шаг основного сценария должен приближать главное действующее лицо use case-а к намеченной цели. Очень много информационных систем, особенно ECM систем этого не делают. Мы называем такие системы чатом. Люди в них мило общаются, пишут друг другу пространные комментарии, а стоит на месте. Эскалация – это один из механизмов повлиять на продвижение кейса. Если какое-то время с кейсом ничего не происходит, то значит требуется внешний по отношению к основному ходу событий механизм, чтоб заставить эти самые события двигаться. Улучшение процесса – еще одни важный момент, который можно включить в ходе выполнения кейса. Зачастую ничего не происходит именно потому, что процесс простроен неправильно. Не надо ждать окончания квартала  для того, чтобы поулучшать процесс. Достаточно включить в реальный процесс его разработчика. Через процесс улучшения надо выстраивать заполнение справочников, доработку правил классификации, адаптацию программного обеспечения.

Case management: основные виды работ: 6 комментариев

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

    И да, в той теории я видел как одно обращение может пораждать множество других, дополнительных. Все это регистрируется, видно отношений обращений друг к другу )

    Теперь изучая ACM понял что это уже придумали до меня )))

    В общем я для себя определил ряд принципов для проектирования процессов, с целью обучения и управления сотрудниками:
    1. Кейсы могут быть маленькими и называться Тикеты (Потоки, Задачи, Операции, Обращения, Инциденты …), а могут быть большими и называться Проекты (Программы, Портфели …)
    Как пример интересного решения в этом направлении это GTD для BuddyPress.
    2. Кейс это универсальная единица операции по процессам. Нужна для того чтобы видеть количество операций, результаты, загрузку человеков, ход выполнения. Например увидеть сколько инцидентов в работе, или сколько проектов у подразделения, кто и сколько проектов ведет обновременно.
    3. В ходе выполнения Кейса, человек может обращаться к другим информационным системам, для ввода или получения какой либо информации; Например: пришел вопрос в тех поддержку по бухгалтерской системе, специалиста может поискать ответы в Яндексе или в КонсультантПлюс или в какой то собственной базе знаний.
    4. Кейсы могут группироваться. Скажем в службу поддержки поступило от пользователей 10 запросов на изменения. 5 отклонили. 5 утвердили. 5 изменений объединяются в один релиз (я релизы из ITIL называю по отчественному – ТЗ). релиз выполняется. затем мы можем увидеть сколько за год было выполнено релизов, сколько изменений и в какой объет ИТ было внесено. Будь то ПО для бухгалтеров или маршрутизатор CISCO.
    5. Кейсы могут разможаться. Скажем поступил вопрос от клиента о продаже ПО. В ходе работы по Кейсу, выясняется что нужно отправить предложение на официальном письме – создается кейс в смежном подразделении, далее нужно подготовить проект договора создается кейс юристам, в ходе кейса пришлось провести штук 10 совещаний (10 итераций по совещаниям), а в конечном итоге выясняется что нужна не продажа ПО, а его внедрение, а это уже совсем другая процедура, требующая предпроегтного обследования и Кейс преобразуется, возможно меняется ответственный, меняется таханомия, теперь это не “заказ на продажу ПО”, а “заказ на внедрение ПО”, и начинается выполнение другой процедуры.

    я все правильно понял? 🙂

    1. Мы вернулись к разговору ACM: парадигма или фича?, который Анатолий инициировал несколько месяцев назад. Тогда, вроде бы, ACM получался фичей. Сейчас, по крайней мере мне, думается что ACM – это парадигма. Причем мощная парадигма процессного управления, рассматривающая не только структурированные процессы и не упускающая контекст, в котором реализуется каждый конкретный экземпляр процесса.

      Кроме плюсов, это имеет и минусы. Сами по себе парадигмы не работают. ACM системам будет очень сложно пробиться на корпоративный ИТ-рынок. С одной стороны BPMS, с другой ECM, с третьей – предметно-ориентированные решения, такие как HR mgmt. systems, ERP, SCM, ITSM решения, любимый мною order fulfillment/management и пр.

      1. Прочитал.
        Как говорится парадоксы это один из равноправных элементов нашего мира )

        Я плохо понимаю кто такой BPM.

        Но скажем знаю как использовать BusinessStudio, DIRECTUM с его WorkFlow. Так понимаю это и есть дети BPM.

        Если так, то я с Анатолием соглашусь. Подходы к управлению процессами в малых фирмах 10-100 человек можно наладить на базе Кейсов. В крупных фирмах, или на производстве, часть процессов стоит загонять в BPM. Правда меня умиляют попытки специаилстов сначала описать процесс в EPC, а потом сделать аналогичный WorkFlow в ECM.
        Если ECM или BPM система позволяет делать гибкие WorkFlow, и тот кто их делает понимает как это нужно делать, то все получается достаточно красиво.

        Пришел Кейс. Записали. Начали выполнять. По ходу выполнения нужно скажем письмо исходяшее отправить. Запустили WorkFlow, письмо ушло на согласование, поставлены ЭЦП, пришло на регистрацию, поставили номер, ушло секретарю, руководителю, подписано, отправлено. Супер! Я не бегаю, за меня бегает WorkFlow. Или аналогичная ситуация с договорами. В общем там где процесс достаточно линеен, последователен, предсказуем – там берем BPM и WorkFlow.
        А там где процесс сложно упорядочить и предсказать берем ACM.
        BPM+ACM=Love.
        Вот только одно но 🙂 Я не смогу бы понять этого без декомпозиции процессов по MECE. Потому формулу бы сделал такую: BPM+ACM+MECE=Love.

        MECE это техника которую нужно полезно применять для декомпозиции процессов с сохранением логики и избежания повторений. Вот тут у меня статья на эту тему http://itau.ru/2011/05/21/protsessyi-organizatsii-opisanie-formalizatsiya-reglamentatsiya-na-primere-printsipov-acm/

      2. >>ACM системам будет очень сложно пробиться на корпоративный ИТ-рынок

        Интересная фраза от “фаната” ACM, да? 🙂 А на рынке персональных систем ACM тем более не нужны, так ведь? Ну и какие выводы будем делать?

        На самом деле могу согласиться с этой фразой, если ее продолжить – “… будет очень сложно поначалу, но вполне возможно”. Занимаясь практической работой, могу сказать, что уже есть весьма приличные клиенты, использующие именно ACM и даже такие, которые используют BPM в связке с ACM, что для меня вдвойне интересно.

        Продвинуть ACM удалось через потребность заказчиков в системе управления поручениями и задачами. Причем как заказчики, так и собственные сотрудники поначалу норовили решить это через традиционную функциональность СЭД, используя категории внутренних документов “поручения” и “задачи”.

        Небольшим административным усилием удалось всех убедить попробовать ACM.
        Пока все довольны. Поэтому я с оптимизмом смотрю на озвученную проблему продвижения ACM на корпоративный ИТ-рынок. К тому же, хоть и есть очевидная перспектива внедрения ACM у наших крупных заказчиков, использующих СЭД, но такие проекты воспринимаю как необязательные “бонусы”, и чуть ли не отмахиваюсь от обсуждения этой темы с крупными компаниями, а рассчитываю, в основном, на средние и небольшие компании, которым надо быстро установить простую систему контроля поручений

  2. Единственное что у меня вызывает сомнение, это все ли потоки работ в организации следует регистрировать как Кейс? Думаю что нет.
    Если говорить об основной детяельности и ключевых участках то да. Будь то продажи, проекты, тех.поддержка.
    А вот скажем делопроизводства или зарплата. В одном случае операция достаточно специфичная, требует ввода множества хитрых данных и заводить кучу таханомий на них как то боязно. Оптимальней этот тип операци

    1. Как то нажал и не дописал предыдущий текст ) и редактирования нет ))

      продолжу…

      Оптимальней этот тип операций оставить в системе ЭДО (если она есть). Хотя если нет, может быть можно будет и на Кейсах вырулить. Надо будет как нибудь попробовать такой проект реализовать )

      Второе это рассчет зарплаты. Происходит 2 раза в месяц, стабильно, соответствующие записи формируются в финансовой системе. Опять же получается, что в этом случае использовать регистрацию Кейсов – особого смысла нет. Записи и так создаются, просто не как Кейс, а как “Начисление зарплаты” или “Выплата зарплаты”.

      Но вот описывать инструкции по принципам ACM на мой взгляд удобно и эффективно во всех случаях. И ссылка на CNews из прошлого поста, где описывается точка зрения EMC на ACM тут мне очень и очень нравится. Во-первых потому что там предусмотрен этап Архива, а EMC знают к чему приводит бардак в архивах. И у меня сейчас как раз большой проект в гос.организации, там эти архивы очень и очень важны ) А во-вторых там нет привязки к регистрации Кейса, там лишь говорится о принципах выполнения процесса как Кейса. И если в текущей системе уже есть записи на ту или иную операцию и по ним можно увижеть показатели процесса, то пусть будут. Для примера это документы в гос.органе. Они там регистрируются. Придумывать регистрацию Кейса не зачем. А вот обращения по услугам или проекты, регистрируются далеко не во всех органах власти. И вот тут БД по Кейсам нужна как воздух. Органы власти регистрируют документы и получаем бюрократию. Начнем регистрировать Кейсы и получим результата ) Вот такой у меня сейчас дивиз на этом проекте ))

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

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