Можно ли преодолеть разрыв между бизнесом и ИТ?

Играть на рояле совсем нетрудно:

нажимайте только нужным пальцем в нужное время на нужную клавишу.

Наблюдение за игрой пианиста

Работая в различных компаниях и разных отраслях экономики, занимаясь информационными технологиями, их трансформацией и доведением ИТ-сервисов до состояния, необходимого бизнесу, я всегда сталкивался с весьма расплывчатым описанием этого состояния. И в конце концов, пришел к выводу, что ИТ-сервисы могут быть признаны хорошими, если станут вести себя как «воздух»[1].

Как понимает ИТ отношения с бизнесом?

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

Так, в отчете PMI[2] о крупных ИТ-проектах говорится, что 45% из них выполняются с превышением бюджета, 7% с превышением времени и 56% проектов не дают заказчикам ожидаемого результата[3]. В России статистика не лучше, и, по моему мнению, основу проблемы составляет именно эта, «правильная» концепция работы с запросами заказчиков.

На практике запросы клиентов выглядят как списки требований, для которых надо искать и разрабатывать системы, проектировать и прокладывать сети, арендовать или строить дата-центры, набирать десятки, а то и сотни сотрудников в ИТ-подразделения.

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

Сформулированные клиентами требования могут быть весьма неплохими, особенно если работа в подобных компаниях в их «прежних жизнях» была автоматизирована и при этом использовались более продвинутые инструменты, чем MS Office. В таком случае вероятность успеха проектов повышается, а если нет — печальный результат практически неизбежен.

Есть ли выход из этой ситуации?

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

ИТ за первый сценарий. Заказчики — за второй. Но чаще всего реализуется третий, циклический, движение по которому идет медленно, нервно и мучительно, с потерей времени, денег и персонала по дороге.

Мое мнение: в чистом виде первый сценарий не будет выполнен никогда (заказчик всегда прав), а вот над вторым можно поработать, и он, если не даст результатов сразу, может серьезно уменьшить число итераций.

Что предлагается изменить?

Сначала простой пример из реальной жизни: запрос на замену сломавшегося компьютера с восстановлением на новом прежних настроек и нужных пользователю программ.

Первый запрос (на саму замену компьютера) был выполнен оперативно и закрыт с отличной оценкой. Вскоре выяснилось, что на новом компьютере не установлен MS Visio, хотя на старом он присутствовал. Создан новый запрос, все сделано быстро, оценка положительная. Спустя некоторое время Visio потребовался пользователю не только для просмотра файлов, но и для редактирования — попытка оказалась неудачной, операция копирования/вставки вызвала аварийное завершение программы. Новый запрос, быстрая реакция ИТ, манипуляции специалиста с настройками и опять успешное завершение. Итог: формально у ИТ три успешно выполненных запроса, загруженные работой специалисты и... недовольный пользователь.

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

С крупными изменениями сложнее, но и здесь ИТ может стать ближе к заказчикам, а для этого нужно следующее:

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

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

Во вторых, передать в ИТ задачу формулирования требований, а с заказчиком согласовывать только итоговый документ, причем использовать язык и понятия, как знакомые клиенту, так и применимые в ИТ-среде.

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

Интерфейсы ИТ для коммуникаций с заказчиками

Первый — это инциденты и стандартизуемые операции:

• По инцидентам (восстановление сервиса) — в простых случаях разрешаются сервис-деском или, после диагностики реального источника инцидента, передаются для разрешения соответствующим специалистам.

• По повторяющимся операциям (от оборудования рабочих мест до открытия офисов) — сотрудниками специализированных подразделений, в соответствии с типом и масштабом операций.

Второй — изменения и проекты:

• По запросам на изменения в бизнес-системах, квалифицированным как обязательные или небольшие, — представители бизнес-подразделений, которых затрагивают изменения в бизнес-системах.

• По остальным (крупным) запросам на изменения — запуск проектов.

Как может выглядеть ИТ для реализации предложенной парадигмы? На схеме представлена версия ролевой ИТ-структуры.

Рис 1. Схема ролевой ИТ-структуры

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

Поддержка бизнес-систем

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

Базовые сервисы

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

Процессы и качество

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

ИТ-сорсинг и разработка

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

Архитектура и стратегия

Формирование будущего ИТ-ландшафта, его привязка к задачам бизнеса, определение наилучшего пути перехода из текущего состояния в будущее, создание плана перехода — такова основная деятельность этого подразделения, которая декомпозируется на:

• разработку целевой ИТ-архитектуры и ИТ-стратегии;

• определение пути развития и проектов, которые нужно выполнить для реализации ИТ-стратегии;

• предложения инноваций для развития и улучшения ИТ-сервисов.

Планирование и эффективность

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

Правила взаимоотношений между бизнес-подразделениями и ИТ

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

Таблица 1.Термины, определения и сокращения

• Заказчики формулируют свои потребности в понятных им терминах, с детализацией, достаточной для проверки их выполнения. Далее потребности осмысливаются аналитиками и оформляются в виде запросов.

• Аналитики отвечают за правильность формулирования запроса, критерием правильности является приемка его реализации заказчиком.

• Если для реализации запросов нужны модификации систем/разработка, то аналитики декомпозируют запросы в задачи, на основании которых разработчики создают задания.

• Разработчики отвечают за правильность формулирования заданий, критерием правильности выполнения заданий является приемка задач аналитиками.

• Реализованные задания тестируется разработчиками, компонуются в задачи, на основе которых они делались, тестируются аналитиками, и после того, как получено подтверждение о реализации всех задач, созданных на основе запросов, заказчики информируются об их удовлетворении.

• В случае сбоя в цепочке в части понимания запроса, задачи или задания, точка ответственности за правильность понимания находится на уровень ниже по процессу от места сбоя, а именно:

- ответственность за правильное понимание запросов и их декомпозиция на задачи ложится на аналитиков.

- ответственность за правильное понимание задач и декомпозиции их на задания — на разработчиков.

Изменения договоренностей

• Сотрудник, инициирующий изменения в договоренностях цепочки запрос-задача-задание, отвечает за обоснование причин изменений.

• Обоснование изменений должно быть содержательным и максимально объективным.

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

• Изменение договоренностей по запросу/задаче без негативных последствий для аналитиков может быть только с согласия заказчика.

• Изменение договоренностей по задаче/заданию без негативных последствий для разработчиков может быть только с согласия аналитиков.

Заключение

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

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

[1] Аналогия с воздухом здесь следующая: когда с воздухом все в порядке — им просто дышишь и о нем не думаешь, а замечаешь его только, если с ним становится что-то не так.

[2] PMI (Project Management Institute) — Всемирная некоммерческая профессиональная организация по управлению проектами

[3] https://www.wrike.com/blog/complete-collection-project-management-statistics-2015, http://www.pmi.org/learning/pulse.aspx