Портал №1 по управлению цифровыми
и информационными технологиями

Может ли Change Management быть “бумажным”?

Опубликовано 1 марта 2016
Рубрики: ITSM, Управление изменениями
Комментарии

Зарылся_в_документах_1Вопрос может показаться странным, но он возник не на пустом месте. Если на этапе разработки процесса нет ясности, каким образом будет решаться вопрос автоматизации, процесс проектируется "на бумаге". Разрабатывается только регламент процесса, для которого пока не предполагается соответствующего функционала в ITSM-системе. Функционала, обеспечивающего возможности учёта объектов управления и направляющего исполнителей ролей процесса по нужному пути. В целом, если автоматизация предполагается на следующем этапе, в виде отдельного проекта, никаких противоречий, вроде бы, нет. Ведь это, как раз, правильно – проектировать процесс от потребностей, а не выстраивать его в зависимости от возможностей конкретной ITSM-системы. Затем сформулировать требования к автоматизации и "уложить" процесс в систему.

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

Кроме того, если неопределённость с будущей ITSM-системой высока, значительно повышается риск. Риск того, что процесс так и останется в полном смысле "бумажным", то есть окажется на полке в сброшюрованном виде, через относительно короткое время всеми забытый. Возникает вопрос, а не имеет ли смысл начать работать "на бумаге", чтобы оттестировать процесс, уточнить требования к автоматизации и только потом переходить к разработке технического решения?
Мысль рациональная, но возникает ряд нюансов. Помимо того, что "бумажная" обработка требует дополнительных ресурсов, она также требует дополнительных манипуляций со стороны исполнителей процесса. Чтобы понять, каких именно, попробуем для начала просто смоделировать работу нашего процесса без системы, на бумаге. Для этого берём лист бумаги и представляем, что это – интерфейс RFC в будущей ITSM-системе. А далее, при заполнении, делаем ряд допущений и предположений. В частности, такие:

  • средствами системы автоматизации обеспечена возможность ведения реестра обращений; то есть нам не надо вручную вести какой-то реестр (в амбарной книге, например, или в любимом табличном редакторе);
  • идентификатор объекта будет создан автоматически;
  • дата регистрации заполнится автоматически;
  • в системе будут обеспечены необходимые для заполнения обращения справочники;
  • обращения можно будет связать между собой; например, зарегистрировать "дочерние" изменения, реализуемые в рамках комплексного запроса на доработку функционала информационной системы;

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

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

Вывод из всех вышеприведённых рассуждений следующий: "бумажный" процесс может быть полезен для его обкатки, но необходимы определённые усилия, возможно несколько большие, чем при внедрении процесса "в комплекте" с автоматизацией, для того, чтобы результаты проекта не оказались в итоге на дальней полке.

«VAP: Управление изменениями и конфигурациями в ИТ»
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

Комментариев: 9

  • Nargiza Suleymanova

    Возможно, это нерепрезентативная выборка, но в моей практике еще не было обкатки процесса на бумаге. Хоть какой-то минимум в виде использования средств электронной почты, пресловутых табличных редакторов, функционала СЭД или средств совместной работы над документами был обязательно. Самым "крышесносящим" вариантом было использование скайпа (я бы не подумала никогда, что им можно инцидент менеджмент поддерживать 🙂

    • Альберт

      Бумажная часть обычно касается документооборота официальных документов. Все остальное как правило по договорённости.

  • Альберт

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

    • Nargiza Suleymanova

      А расскажите на примере, как это работает? У меня пока в голове картинка не складывается.

      P.S. Для меня исключение – это госорганы, которые по старинке ногами приносят служебки, приказы, распоряжения и т.д. Но мы же вроде про ИТ-процессы здесь говорим.

    • Артем Мукосеев

      Действительно, очень интересный опыт! Альберт, Вы не могли бы чуть подробнее рассказать про структуру бумажного варианта для упомянутого Вами случая? Если это возможно.

  • Максим

    Какой-то гипотетический случай).

    Я не представляю себе в принципе внедрение ITIL-практик в отсутствии соответствующей им технологической подосновы – то, что называется ITSM suite.

    Поэтому ответ простой – никакого бумажного(или около бумажного) внедрения ITIL быть не может))

     

  • Сергей

    А как вообще вести например конфиг в "бумажном" виде? (или экселе)

    Связей только у серверов столько что никакой эксель не вместит… Есть какие-то мнения опыт на эту тему?

  • Файрушин Дмитрий

    P.S. Для меня исключение — это госорганы, которые по старинке ногами приносят служебки, приказы, распоряжения и т.д. Но мы же вроде про ИТ-процессы здесь говорим.

    Наргиза, скажу по секрету, так работает много компаний, причем в Москве, причем очень известных)

    • Nargiza Suleymanova

      Дмитрий, ну вот. Пойти теперь об стенку убиться осталось )))


Добавить комментарий для Артем МукосеевОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM