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

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

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

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

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

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

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

ИНТЕНСИВ С ТРЕНЕРОМ

VAP: Управление изменениями и конфигурациями в ИТ

Повысить долю успешных изменений, снизить риски, знать всё про конфигурации