Процессы по фэн-шуй: как устроена профессия методолога

Привет! Меня зовут Лариса Иншакова. Более 15 лет я работала в одной из крупнейших консалтинговых организаций. С моим участием и под моим управлением выполнены десятки проектов: от тех, в которых надо провести аудит и выработать концепцию улучшения, до тех, где одновременно внедрялись более десяти процессов. После передачи проекта под контроль заказчика у меня не было уверенности, что выстроенные процессы продолжают приносить ожидаемые результаты. Поняв, что воспринимаю каждый проект как родного ребенка, я решила воспитывать «ребенка» под собственным присмотром и пришла работать в Газпромбанк на должность начальника Управления сопровождения IT-сервисов. Расскажу, что за процессы я имею в виду, как их внедряют и чем вообще занимается методолог.

Итак, я — методолог. Когда меня спрашивают, чем я занимаюсь, кратко отвечаю: навожу порядок. Или: делаю так, чтобы все работало как по фэн-шуй. Мы анализируем процессы в компании и можем сказать, что работает хорошо, что плохо, и как надо поменять методику (читай: «правила работы») для исправления ситуации.

Раньше, для получения доступа к IT-ресурсам, на каждый приходилось оформлять отдельное обращение, и в каждом из них жила своя цепочка согласования. Это было долго, дорого и неудобно, а сотрудники воспринимали такой подход как недружелюбный. Чтобы улучшить ситуацию, мы стали применять заранее согласованные типовые наборы прав доступа - типовые профили пользователя (ТПП) в зависимости от должности и роли сотрудника. Теперь согласование либо не требуется вообще, либо нужно согласовать только одно обращение с непосредственным руководителем, а все остальные обращения на доступ создаются автоматически в соответствии с ТПП и сразу отправляются на исполнение.

В команде прикладного сопровождения информационных технологий мы анализируем деятельность нескольких подразделений банка, стандартизируем и совершенствуем процессы, которые выполняют сотрудники команд IT-поддержки и сопровождения.
Мы используем лучшие мировые практики в области управления IT-услугами (ITSM — IT Service Management). Киты, на которых держится такое управление, — это Процессы, Люди и Технологии: нужно описать процесс, назначить роли и обучить персонал, внедрить инструменты автоматизации для учета и контроля. Вторым эшелоном идут: Культура, Риски, Партнеры и многое другое.

Кроме того, мы стоим на страже необузданных идей сравнивать «теплое и мягкое», чтобы коллеги не пытались внедрить изменения ради изменений: важно отбирать только те, которые будут работать и давать реальный результат.

Инициатива — это прекрасно, но зачастую после выяснения задачи становится понятно: предложенная идея по доработке средств автоматизации не решает задачу до конца или не приводит к заметной экономии. Поэтому мы регулярно задаем коллегам вопросы: «зачем это делать?», «кому это надо?» и «а что, если этого не делать?».

Иными словами, стараемся быть беспристрастными и достаточно жесткими, чтобы объективно оценить ситуацию и внедрять только нужные улучшения.

Напомню главную разницу между процессом и проектом, а точнее — проектом «водопадного» типа, цели которого известны до старта реализации. Суть в том, что проект конечен по времени, а процесс — нет. После запуска процесс может быть остановлен только в случае отказа от целей и задач, которые он призван выполнять.

Приведу аналогию с постройкой дома. Молодая семья самостоятельно или с привлечением подрядчика построила дом. Строительство — это проект, у которого есть срок, ресурсы и ожидаемый результат. Когда что-то идет не так, может измениться один или несколько изначально запланированных параметров: сдвинуться срок, расшириться смета расходов, трансформироваться внешний вид конечного продукта и многое другое. В процессе постройки команда думает в основном об устранении возникших проблем. Опытные команды, помимо этого, управляют рисками, чтобы снизить количество возможных проблем и степени их влияния на проект. Но крайне редко команда задумывается о том, как потом молодой семье жить в построенном доме.

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

Необходимость организовать процессы обслуживания как раз и заставляет задуматься, как все спланировать заранее. Специалистам сопровождения намного удобнее работать по правилам, разработанным методологами процессов IT-поддержки. Их не нужно искать, когда надо разобраться, как все устроено или как устранить неисправность. Методологи стараются выполнять свою работу заблаговременно и «незаметно». У них в «аптечке» есть самые разные лекарства, которые в конечном итоге помогают тем, у кого заболело, сломалось, зависло или потерялось. Это и называется словами «поддержка», «сопровождение» и «эксплуатация».

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

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

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

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

Ключевая задача при внедрении — бесшовная интеграция. Мне сложно назвать хотя бы один процесс, который существует сам по себе, то есть совсем не обменивается информацией с другими процессами. Вероятно, можно возразить примером, когда в компании идентифицированы очень крупные процессы, но такой подход просто перекладывает вопрос интеграции процессов между собой на интеграцию отдельных этапов единого укрупненного процесса. Можно было бы выпустить единый регламент под названием «IT-поддержка», но тогда внутри мы бы вернулись к зонам ответственности за разные области специализации и свели бы задачу к предыдущей, а именно: как разделить процесс на этапы, за которые однозначно определена ответственность, цели, показатели эффективности.

Рано или поздно проект заканчивается и про него забывают. А процесс и методолог — бесконечная работа. Это не про то, что вы пришли в какую-то организацию, посоветовали, как лучше сделать, и ушли — так работают внешние консалтинговые компании. Процесс важно постоянно видоизменять, поскольку жизнь тоже все время меняется: как внутри организации, так и снаружи. Это могут быть новые требования, поступающие из внешней по отношению к банку организации, например, новые требования регуляторов. Или смежные процессы, которые переплетены с другими. Куда и зачем идти — всегда решает стратегия компании. Через бизнес-стратегию разрабатываются планы достижения поставленных целей, в том числе с помощью изменения подходов к выполнению тех процессов, которые ранее считались успешными. Кто не занимается постоянным совершенствованием, неминуемо отстанет от конкурентов.

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