Управление изменениями. Standard+Case approach

SplusCНа прошлой неделе увидела свет новая книжка ИТ-скептика Роба Ингланда(Rob England) Plus! The Standard+Case Approach Конечно же я не смог удержаться от приобретения kindle версии данной книги. В своей книге Роб сделал довольно простую и в то же время очень важную вещь, объединил два подхода управления бизнес-процессом заказа и предоставления услуг. Стандартный подход, описанный в многочисленных книжках по ITIL и ITSM и навевающий скуку на большинство пользователей ИТ-услуг и адаптивный кейс-менеджмент, используемый в проектах и другой человеко-ориентированной деятельности.

В течении предыдущих трех лет различные авторы предпринимали попытки такого объединения. Кто-то говорил о том что процессы бывают предсказуемые и непредсказуемые. Другие предлагали использовать метод case management для обработки исключений, возникающих в ходе традиционного предопределенного процесса или наоборот, стартовать из кейса процессы, необходимые для его решения. За всеми этими баталиями можно проследить на страницах этого блога. Роб изящным образом примерил оба подхода, введя в рассмотрения каталог стандартных процессов. Эта идея была озвучена в прошлом году на круглосуточном марафоне по управлению ИТ сервисами #tft12 и более подробно описана в этой книге. При получении запроса от клиента мы просто находим необходимую модель процесса в каталоге и запускаем его. Если вдруг требуемая модель процесса не обнаружена (или в ходе исполнения процесса выяснится, что такая модель не подходит), то запрос отправляется в категорию кейсов и реализуется при помощи этой практики (свой вариант картинки я приводил на встрече клуба 4CIO:  Adaptive Case Management. Внедорожник для бизнес-процессов ). Естественно, после успешного выполнения кейса реализовавшийся сценарий бизнес-процесса сохраняется в каталоге моделей и в следующий раз может быть использован в качестве стандартного. В эту схему успешно вписывается и непрерывное улучшение бизнес-процессов, столь почитаемое консультантами и аналитиками. Проникнувшись метафорами автора о дуализме традиционного BPM подхода и адаптивного управления кейсами  в стиле инь-ян, я даже предложил Робу логотип Standard+Сase стилизованный под символ taichi (см. выше).

Почему же данный подход интересен для процесса управления изменениями (change management, CHG). В первую очередь потому, что CHG это основной управляющий процесс в предоставлении ИТ услуг. Сам этот процесс ничего не производит и ничего не чинит. Процесс управления изменениями управляет другими ИТ процессами. Настройка именного этого процесса требует от организации наибольшего мастерства. Именно этот процесс формирует ИТ ландшафт (помните, основная причина it compelxity — изменения). Именно здесь труднее всего отличить стандартные изменения от больших и порой плохо предсказуемых перемен.

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

SplusC

Реклама

9 Comments

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

    Ответить

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

      Ответить

  2. Да, при внедрении ACM тоже столкнулся с этим конфликтом идеологии 🙂
    Ответ кстати нашел, причем в неожиданном для самого себя месте 🙂
    Я думал что знал ИСО 9000 и что хорошо разбирался в понятиях управления процессами. А как оказалось — показалось.

    В общем то речь идет о 2-х давно известных сущностях:
    1. процессы — преобразуют входы в выходы и делают продукты
    2. процедуры — определенный порядок действий

    Процесс может соответствовать процедуре. Но не всегда. Иногда процесс может принимать вид множества разных процедур.
    Примеры:
    1. оформление командировки — тут как правило легко обойтись одной процедурой
    2. техническая поддержка — вот тут процедур может быть огромная куча. Причем не все из них могут быть описаны. Но часть описывается точно.

    Процедура может иметь следующие формы:
    1. понимаема, но не описана, делается человеком: получить выписку из ЕГРЮЛ юристом
    2. описана, но делается руками: приборка помещения
    3. автоматизирована, но с участием исполнителей: сменить права доступа в бух системе
    4. автоматизирована полностью, без участия людей: сменить тарифный план на мобильном

    А дальше вводится механизм 3-х уровней эскалации:
    1. первая линия — контакт центр пытается закрыть сообщение сразу на входе без эскалации дальше
    2. вторая линия — отдел по компетенции, если контакт центр не справился
    3. третья линия — руководство — если отдел по какой то причине не смог решить вопрос

    Таким образом удалось получить интересные результаты:
    1. простая система с точки зрения клиента, он не парится и у него просто есть единый контакт центр куда можно обратиться
    2. контакт центр за счет того что процедуры описаны все больше и больше закрывает вопросов сам без эскалации дальше. Дожили до того что в последний месяц контакт центр закрыл вопросов по ИТ больше чем сам отдел ИТ 🙂
    3. если специалист отдела начал тупить или это вопрос на стыке отделов, который не понятно как решать — такой вопрос делегируется на уровень руководства. Ко мне как к заместителю директора прилетали такие задачи, но очень редко. При правильной системе — 99% вопросов закрывается на первых 2-х линиях. И только очень редкие и очень сложные как правило с организационной точки зрения вопросы — прилетают на уровень руководства.

    Конечно же внутри отдела есть своя система 3-х уровневой эскалации. Там есть младшие и ведущие специалисты, есть руководитель отдела. Там также — сначала на младшего, потом поднимается. Либо сразу на руководителя отдела, если вопрос спорный и не понятный. Он принимает решение и резолюцией назначает ответственногою

    Все эти методы стары как мир. Известны еще со времен 50-х годов при построении первых систем документооборота уровня предприятия. В России они больше известны под брендом ГСДОУ.

    ACM — лишь меняет формат носителя, не бумага-страница, а веб-страница. Но суть процессов и процедур — никуда не делась.

    Ответить

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

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

Логотип WordPress.com

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

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s