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

На мой взгляд, именно здесь заканчивается история личного эксперимента и начинается вопрос организационной ответственности.

Пока мы проверяем гипотезу, важно понять: работает ли идея и даёт ли полезный эффект? Когда решением начинают пользоваться регулярно, возникают другие вопросы: кто заметит ошибку, кто восстановит работу и кто проверит, нужен ли результат по-прежнему?

Причём заметный сбой - не единственная проблема.

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

Кто должен это обнаружить?

Ответ «ИТ» кажется очевидным, но недостаточным. Техническая поддержка может проверить выполнение программы, однако не всегда способна определить, соответствует ли расчёт изменившейся бизнес-задаче.

Я бы разделил три ответственности.

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

Технический ответственный обеспечивает работоспособность, безопасность и восстановление решения, сопровождает согласованные изменения. Это не обязательно его первоначальный автор.

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

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

До регулярного использования я бы договорился о нескольких вещах:

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

Это не означает, что каждый макрос следует превращать в большой ИТ-проект. Уровень поддержки должен соответствовать последствиям ошибки. Но небольшой размер файла ещё ничего не говорит о важности процесса, который от него зависит.

Есть и ещё одна, менее очевидная обязанность: вовремя отказаться от автоматизации, которая выполнила свою задачу.

Когда-то инструмент действительно экономил часы. Затем появилась новая система или изменился процесс, а вокруг старого решения остались проверки, инструкции и привычные действия. Так вчерашнее улучшение само может стать ритуалом.

Автору бывает особенно трудно это признать: в решение вложены усилия, с ним связано профессиональное признание. Но полезность в прошлом не гарантирует необходимости в будущем. Отмена удачного инструмента не обесценивает его создание - возможно, его время просто прошло.

Поэтому ответственность за автоматизацию - это не только обязанность поддерживать её в рабочем состоянии. Это ещё и готовность проверить, продолжает ли она приносить пользу, и принять решение об изменении или отключении.

А кто в вашей организации замечает, что исправно работающая автоматизация стала выдавать неверный или уже ненужный результат? И кто вправе решить, что её пора остановить?