Мальтийский крест взаимоотношений ИТ и бизнеса

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

Ричард Бакминстер Фуллер

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

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

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

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

· Кто является владельцем информационной системы (бизнес-приложения) и кто определяет, что нужно/можно в ней изменить и как нужно/можно изменить?

· Чем обоснован конкретный запрос на изменение или проект и как он влияет на другие процессы и бизнес-приложения?

· Как должно быть организовано управление изменениями с учетом обеспечения выполняемых бизнес-операций, принципов управления процессами (бизнес-технологий), требований управления бизнес-приложениями и их функциональных возможностей (ИС/ИТ), правил управления проектами модернизации информационных систем (проектных технологий)?

Не могу сказать, что это единственные вопросы, на которые нужно ответить, но они представляются наиболее актуальными для рассмотрения сложной системы взаимоотношений (для простоты восприятия она показана в виде гиперсферического октаэдра[1] на рис. 1).

Рис. 1. Система взаимоотношений ИТ и бизнеса в виде гиперсферического октаэдра

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

Кто хозяин ИС

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

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

Конечно, при определенной сноровке можно и к «Феррари» приделать колеса от БелАЗа, но это будет уже совсем другая машина...

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

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

Ключевые пользователи ИС — опытные сотрудники бизнес-подразделений, внутренние эксперты по функциональности системы являются представителями владельца автоматизированных процессов на оперативном уровне (вспоминая ранее приведенную аналогию — профессиональными водителями). Они обеспечивают горизонтальное взаимодействие с сотрудниками ИТ-подразделений, ответственными за штатное функционирование конкретной информационной системы (читай: профессиональными механиками). Эти сотрудники бизнес-подразделений могут решать до 20% от общего количества ошибок, связанных с некорректным применением функциональности ИС, и большинство ошибок ввода данных, выполнять запросы рядовых пользователей на консультации в рамках процесса управления инцидентами. Ключевые пользователи, непосредственно принимая участие в процессе управления изменениями в качестве бизнес-экспертов, обеспечивают точность формулировок в запросах на изменения (что нужно изменить в ИС) для последующего согласования с ВБП или СТО, которые подтверждают соответствие содержащихся в запросе требований целям и задачам бизнес-подразделений. Такие подтвержденные ВБП или СТО будут основанием для дальнейшей обработки запроса сотрудниками ИТ-подразделений, ответственными за штатное функционирование конкретной информационной системы, — они определяют, как нужно/можно реализовать необходимое изменение в ИС, в какие сроки и с каким приоритетом.

Требования и «хотелки»

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

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

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

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

Улучшения и одноразовые требования — это третья группа и вечная «зона боевых действий» бизнеса и ИТ. Данная группа в свою очередь содержит два вида требований: разумные улучшения и «хотелки». Разумные улучшения, как правило, реализуются с третьим приоритетом при наличии необходимых ресурсов. Однако ожидания по приоритету реализации запросов второго вида, в зависимости от должностного положения инициатора — пользователя ИС, в ряде случаев может быть выше максимального. Но задумывается ли пользователь о том, сколько стоят «хотелки», о том, что до 80% заказываемых отчетов понадобятся лишь несколько раз, или о том, что значительное количество мелких изменений нарушает стабильность приложений. Причем авторы таких запросов нередко в качестве дополнительного аргумента задают вопрос: «Ну что вам стоит внести это небольшое изменение?». Ответ прост: получение информации не должно стоить дороже, чем сама получаемая информация.

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

Чтобы что-либо изменить, постройте новую модель …

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

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

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

1. Выполнение ежедневных операций в соответствии с существующими бизнес-процессами и контроль выполнения этих процессов;

2. Развитие бизнес-технологий, направленных на оптимизацию таких бизнес-процессов;

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

4. Сопровождение/оперативная модернизация компонентов единой информационной среды (информационных систем и технологий), используемых для автоматизации бизнес-процессов, и ИТ-поддержка ежедневных операций бизнес-подразделений.

Рис. 2. Мальтийский крест взаимоотношений ИТ и бизнеса

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

Отсутствие института бизнес-архитекторов (БА) и бизнес-руководителей, ответственных за автоматизацию и модернизацию технологий (или CTO), является одним из слабых мест в системе управления многих российских компаний, не говоря уже об архитекторах данных и НСИ (MDA, Master Data Architect). Как правило, эта группа может быть представлена методологами по бухгалтерскому и налоговому учету и юристами, которые хорошо знают и понимают требования законодательства, но очень слабо разбираются в вопросах моделирования и оптимизации бизнес-процессов и данных. Но при этом такая группа должна быть ответственной за своевременное инициирование и подготовку запросов на изменения, связанных с законодательством, за построение моделей и описаний бизнес-процессов, за решение вопросов по интеграции процессов смежных функциональных направлений, проверку и подтверждение запросов на изменение/проекты от первой группы. Эта группа также обеспечивает формирование сценариев тестирования и проверку их результатов, отвечает за выполнение задач по оптимизации мастер-данных (или нормативно-справочной информации).

Помимо координации реализуемых проектов, предусматривающих модернизацию существующих процессов и внедрение новых ИС, на третью группу должны быть возложены задачи управления пулом проектов/программ и проработка вопросов, связанных с управлением организационными изменениями и минимизацией сопротивления таким изменениям. Соответственно, в состав третьей группы кроме руководителей проектов (РП) и проектных команд внедрения могут быть включены руководитель и специалисты офиса управления программами/проектами (РМO, Program management office) и специалист по организационным изменениям (OCM, Organization Change manager).

Не всякая компания может позволить себе создание центров компетенций по каждой ИС и масштабное внедрение основных рекомендаций ITIL, но при этом основной фигурой в оперативном взаимодействии с ключевыми пользователями ИС (КП), бизнес-архитекторами (БА) и руководителями проектов по текущим задачам управления инцидентами и изменениями (в том числе реализуемым в рамках проектов) должны стать менеджеры приложений (МП). МП отвечают за штатное функционирование конкретной ИС для автоматизации бизнес-процессов, обеспечивают предоставление экспертизы по данному бизнес-приложению. Они должны контролировать интеграционное тестирование по выполненным запросам на изменение, а также прием в эксплуатацию результатов проектов. Для обеспечения общего видения компонентов единой информационной среды компании в четвертой группе также необходимо присутствие технического (системного) архитектора (ТSA).

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

Кроме того, в модели достаточно просто определить роли, отвечающие за решение задач стратегического взаимодействия между группами, — на схеме (рис. 2) они обозначены трехбуквенными аббревиатурами ролей. Тактические вопросы по каждой из групп решают руководители и специалисты, чьи роли обозначены двух- и трехбуквенными аббревиатурами (например, ВБП – ВИС – КП для группы бизнес-операций).

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