Хотели бы вы, чтобы руководители предприятий и ИТ могли лучше работать вместе, совместно работать над проектами и в полной мере обмениваться информацией? Если вы похожи на большинство ИТ-руководителей, ответ — да. Преимущества эффективного сотрудничества между бизнесом и ИТ включают в себя специальные проекты, которые лучше соответствуют бизнес-целям, улучшенное управление изменениями и более активное участие в новых инициативах.
Мало того, эффективное сотрудничество с бизнесом — это навык выживания для современных технологических лидеров. В 2021 году исследование Gartner показало, что больше ИТ специалистов нанимается для функций вне ИТ департаментов. Между тем, с помощью простых в использовании облачных решений без кода или с минимальным кодом, которые легко доступны, технически подкованные бизнес-профессионалы могут справиться с большей частью своих собственных технологий без какой-либо помощи. «Я думаю, перед ИТ-директорами стоят серьезные задачи, — сказал Даррен Топхэм, старший аналитик Gartner. «Они больше могут владеть всеми ИТ ресурсами. Должно быть сотрудничество и рассредоточение».
№367 — Свой ИТ БИЗНЕС? Советы из нашего опыта. ИДЕИ для БИЗНЕСА!
Очевидно, что расширение сотрудничества между бизнесом и ИТ должно быть приоритетом для большинства технологических лидеров. Но как это сделать? Ниже пять ИТ-руководителей рассказывают о стратегиях, которые сработали у них.
Интересуйтесь как это работает
Этот подход имеет различные названия и конфигурации, но он всегда предполагает, что ИТ-специалисты проводят время, наблюдая за тем, как их коллеги по бизнесу выполняют свою работу, какие инструменты они используют и как все это можно улучшить.
Когда три года назад Даррен Персон пришел в компанию The NPD Group, занимающуюся маркетинговыми исследованиями, в качестве глобального ИТ-директора, он захотел узнать, как обстоят дела в компании на местах.
Даррен Персон, ИТ-директор, The NPD Group:
«Я обнаружил, что, когда люди приходят в руководство компаний, многие из них никогда не вникают в суть дела, не понимают, как на самом деле работает и функционирует бизнес», — говорит он. Это наблюдение в равной степени относится как к ИТ-специалистам, которые занимаются техническими вопросами, так и к руководителям высшего уровня, которые, как правило, далеки от повседневной работы, говорит он.
Поскольку NPD — компания, занимающаяся данными, а Персон курирует архитектуру данных, «я владею производством», — говорит он. «Поэтому я посчитал крайне важным, чтобы я понимал, как это работает на самом деле».
Слишком много ИТ-директоров тратят все свое время на то, чтобы сосредоточить внимание на руководстве компании и совете директоров, добавляет он, и работают только с одним или двумя уровнями прямых подчиненных. «Когда вы принимаете решения и определяете стратегию, есть много вещей, которые спускаются вниз к сотрудникам и не всегда видны».
Персон обнаружил, что, если он приходит к людям в офис и наблюдает за их работой, они разговаривают с ним более свободно, и он может лучше понять их повседневные проблемы. Этот процесс показался ему настолько полезным, что он оформил его в программу под названием «День из жизни». Сегодня все новые сотрудники NPD проходят через эту программу, которая представляет собой сочетание видеозаписей, встреч и (до пандемии) посещений офисов для наблюдения за тем, как люди выполняют свою работу. Участники проводят от нескольких часов до нескольких дней, изучая работу различных подразделений компании. Когорты новых сотрудников из разных областей NPD проходят эту программу вместе, добавляет он. «Это создает некую общность с людьми, с которыми вы обычно не общаетесь».
Самым большим преимуществом является более тесное сотрудничество, говорит Персон. «Вы строите эти отношения, вы устанавливаете эти связи, которых, возможно, у вас не было раньше». Наблюдение за тем, как люди выполняют свою работу, также позволило экспертам NPD по технологиям сделать эту работу более эффективной. «Многие люди указали на некоторые виды работ, которые они выполняли очень ручным способом», — говорит Персон. «Это открыло массу проектов, в рамках которых мы могли бы создать инструменты для поддержки команды. Многое из того, что мы делаем сейчас в области искусственного интеллекта и машинного обучения, было сделано благодаря встречам с этими людьми».
Внедрение
Один из способов убедиться в том, что ИТ-специалист полностью понимает потребности отдела или бизнес-подразделения, заключается в том, чтобы ИТ-специалист стал частью этого отдела или бизнес-подразделения. Он может по-прежнему подчиняться ИТ-специалисту, или может быть в структуре бизнес-подразделения, но работать в тесном сотрудничестве с ИТ-специалистами.
Притхви Мулчандани, вице-президент по ИТ бизнес-приложениям, Deltek:
По словам Притхви Мулчандани, вице-президента по ИТ бизнес-приложений, такой подход оказался очень успешным в компании Deltek, производящей программное обеспечение на основе проектов. «У нас есть команды по всему бизнесу с такими названиями, как Customer Care Operations или Financial Systems», — говорит он. «Они не подчиняются ИТ-директору, они подчиняются финансовому директору, директору по работе с клиентами и т.д. Это команды достаточно технических специалистов, работающих в бизнесе».
Эти сотрудники нанимаются бизнес-подразделениями, часто по согласованию с ИТ. «Как правило, в их обязанности входит предоставление поддержки первого уровня бизнес-пользователям, разработка отчетов и удовлетворение потребностей пользователей в аналитике и данных», — говорит он. «Они также будут заниматься более традиционными ИТ-проектами, например, если у нас есть проблема в определенном бизнес-процессе и мы хотим провести исследование, чтобы выяснить, есть ли решение, которое мы можем купить и внедрить. Они будут играть ведущую роль, по крайней мере, на начальном этапе».
Интеграция в ИТ-департамент специалиста из бизнеса
Хотя внедрение ИТ-специалистов в бизнес-подразделения более распространено, некоторые ИТ-лидеры находят успех в противоположной стратегии: внедрении бизнес-специалистов в ИТ.
Майк Вэнс, исполнительный вице-президент по профессиональным услугам компании Resultant:
«Я взял в свою команду человека из финансового отдела, который не знал ИТ», — рассказывает Майк Вэнс, исполнительный вице-президент по профессиональным услугам в компании Resultant, специализирующейся на техническом консалтинге. «Сейчас этот человек является Scrum-мастером в крупной страховой компании. Я взял его потому что хотел, чтобы он наладил отношения с бизнесом, а затем передали их обратно». Вэнс часто использовал этот подход, нанимая ИТ консультантов из других отделов, например, из HR.
По его словам, должность ИТ консультанта может показаться похожей на должность бизнес-аналитика, но на самом деле это гораздо больше. «Работа заключается в том, чтобы убедиться, что вы полностью понимаете, чего пытается достичь бизнес, а затем вернуть это обратно и сформулировать это для ИТ, потому что именно в этом случае всегда возникает разрыв». У ИТ консультантов уже есть авторитет благодаря их контактам в бизнесе, потому что они пришли оттуда и уже хорошо знакомы с функциями и проблемами этой области.
ИТ консультантам приходится завоевывать доверие своих новых ИТ-коллег. «Это происходит, как только вы устраняете для них барьеры, ускоряя работу», — говорит Вэнс. Или возвращаясь к бизнесу, чтобы сказать: «Эй, то, о чем вы просите, на самом деле является значительным изменением в том, как настроена система. Можем ли мы найти другой способ добиться этого?». Именно эта промежуточная работа является действительно мощной».
Межфункциональные команды
Одним из наиболее известных и эффективных способов налаживания сотрудничества между бизнесом и ИТ являются межфункциональные рабочие группы. Эти команды объединяют ИТ-специалистов со специалистами из других областей бизнеса для совместной работы над проектом или инициативой. По словам Топхэма, они могут работать от месяца до трех месяцев или года, и у них всегда есть конкретная цель.
По словам Топхэма, этот подход становится все более распространенным и формализованным: компании начинают включать межфункциональные команды в свои организационные схемы и все чаще организуют их деятельность, чтобы убедиться, что сотрудники с определенным набором навыков доступны там и тогда, где они нужны.
По крайней мере, в некоторых случаях межфункциональные команды становятся постоянным элементом взаимодействия бизнеса и ИТ. До Resultant Вэнс был ИТ-директором в компании Steak n Shake, где он также вводил ИТ цепочки, как и в Resultant. Но в этой очень большой организации он также создал консультативные советы по бизнесу (BAB), в которых ИТ-сотрудники регулярно встречались с руководством различных функций для обсуждения их приоритетов и принудительного ранжирования этих приоритетов.
По его словам, это положило конец тому, чтобы приоритеты ИТ-проектов определялись в ходе неформальных разговоров в коридорах. «Потому что в ответ можно было услышать: «Ну, это номер 15 в вашем списке». По словам Вэнса, это не только помогло всем понять, какие проекты являются наиболее срочными, но и обеспечило подотчетность ИТ-отдела. «Поскольку вы общаетесь еженедельно, они видят статус своих проектов. Вы можете сказать: „Эй, мы ждем от вас ответа по этому вопросу“ или „Это сорвалось, и вот почему“». Таким образом, помимо лучшей согласованности, BABs также обеспечили большую прозрачность.
Обучение для людей, не связанных с ИТ (и наоборот)
Один из лучших способов улучшения согласованности и сотрудничества между бизнесом и ИТ — это понимание технологий сотрудниками, не являющимися ИТ-специалистами. Исходя из этого, многие компании предлагают образовательные программы, в рамках которых ИТ-специалисты обучают своих коллег, не являющихся ИТ-специалистами, работе с системами, которые управляют бизнесом. Эти программы могут варьироваться от простых встреч «обучение на обеде» до официальных образовательных программ, как, например, в страховом гиганте Liberty Mutual, который создал внутреннюю программу технической грамотности для своих нетехнических сотрудников.
Эндрю Палмер, ИТ-директор, Liberty Mutual:
«Это учебный план, который начинается с двухдневной погружающей основополагающей программы», — говорит Эндрю Палмер, ИТ-директор. «Первоначально мы начали со 100 лучших руководителей, но мы расширяем программу». На данный момент около 1 000 руководителей Liberty Mutual прошли эту программу с момента ее начала в 2019 году. Совсем недавно компания также создала видеоверсию для самостоятельного обучения, которую сейчас предлагает сотрудникам Liberty Mutual по всему миру.
Учитывая аудиторию, учебная программа на удивление продвинутая. «После того, как они пройдут базовый курс, у нас есть модули, посвященные таким вещам, как системы данных и понимание, безопасность, новые технологии, телематика и всевозможные глубокие погружения в эти области. Наша цель не состоит в том, чтобы они ушли с кодированием, но мы не хотим и приглушать его», — говорит он.
Толчком к созданию программы послужило решение высшего руководства, которое осознало, что 110-летняя компания сталкивается с более молодыми и цифровыми конкурентами. «Мы очень быстро поняли, что большая часть разрушений и инноваций будет происходить на стыке бизнеса и ИТ, — говорит Палмер.
Это риск для крупной компании, добавляет он, потому что в технологических стартапах все досконально разбираются как в бизнес-модели, так и в технологии — нет разделения на бизнес и ИТ. «Существует определенная базовая техническая грамотность, которая необходима для общения на этом перекрестке, и обеспечение этого было целью программы», — говорит он.
Одним из непосредственных результатов стало то, что руководители компаний Liberty понимают технологический долг гораздо лучше, чем раньше, говорит Палмер. «В прошлом технический долг был чем-то, над чем ИТ-отдел работал в фоновом режиме и просто делал это в качестве ночной работы. Сейчас мы имеем гораздо более тесную связь между принимаемыми бизнес-решениями и стоимостью реализации этих решений в инфраструктуре».
Это также означает, что руководители предприятий лучше понимают свои возможности по управлению технологическими затратами. Они также научились учитывать возможности ИТ на каждом этапе принятия решений. «Наши дискуссии по планированию стали гораздо более насыщенными», — говорит Палмер.
Совсем недавно компания решила перевернуть популярную программу, создав курсы о страховом бизнесе для ИТ-специалистов. Это особенно ценно, говорит Палмер, после цифровой трансформации компании, в результате которой многие роли бизнес-аналитиков были упразднены.
«Когда мы перешли на гибкую структуру, владельцы продуктов работали непосредственно с инженерами», — говорит он. «Было очень важно, чтобы инженеры решали большую часть проблем, связанных с бизнес-возможностями, чтобы убрать этот шаг переводчика, а также проводить гораздо больше тестирования». По его словам, программа бизнес-грамотности для ИТ-специалистов уже прошла пилотный проект с участием 40 инженеров и будет развернута в этом году.
Совет Палмера другим руководителям ИТ-компаний, которые хотят запустить образовательные программы? «Не разбавляйте ее водой и не делайте слишком абстрактной». Признайте, что бизнес-лидеры, которые досконально понимают, чем занимается ИТ, станут лучшими партнерами. «И пусть ваши старшие ИТ-руководители содействуют и выступают в роли учителей. В противном случае вы упустите возможность укрепления доверия».
Участие в корпоративных программах и мероприятиях
ИТ-директор AppDirect Пьер-Люк Бизайон ранее работал ИТ-директором в Cirque du Soleil Entertainment Group, административной штаб-квартире знаменитой цирковой компании в Монреале, Канада. ИТ-отдел компании, состоящий из 120 человек, управлял системами, такими как ERP-системы и системы управления персоналом, которые поддерживали работу компании (технологией представления занимались другие компании).
Пьер-Люк Бизайон, ИТ-директор компании AppDirect:
Когда Бизайон впервые пришел на эту работу, он обнаружил, что ИТ-отдел нуждается в обновлении имиджа. «ИТ-отдел находился в немного стереотипной ситуации — знаете, как будто ИТ в подвале, где WiFi никогда не работает. Не очень-то хорошая картина».
Он начал улучшать ситуацию, реструктурировав ИТ-отдел. Если раньше сотрудники были сгруппированы по своим конкретным функциям, таким как бизнес-аналитик, менеджер проекта или разработчик, то теперь он создал специальные команды, которые объединили эти функции для обслуживания конкретной области бизнеса, такой как HR, финансы или креатив. Это позволило добиться большей прозрачности, более четкой ответственности и определения приоритетов проектов.
В то же время Бисайлион хотел сделать что-то конкретное и незамедлительное, чтобы повысить авторитет ИТ-отдела в организации и его собственную самооценку. Приближался Хэллоуин — время, когда корпоративная группа всегда устраивала костюмированный парад вокруг здания своей штаб-квартиры. «Вы можете себе представить, что в Cirque du Soleil Хэллоуин — это очень важное событие, которое отмечается во всей организации», — говорит он. Он решил, что ИТ-отдел примет самое активное участие в параде.
Бисайлион и его команда остановились на Грю и Миньонах как на теме, которая может вызвать у людей желание присоединиться к параду. Он вызвался быть Грю, что потребовало нескольких часов в кресле гримера. Хотя он не требовал участия в параде, он заказал достаточно желтых футболок и шляп, чтобы каждый сотрудник ИТ-отдела превратился в Миньона.
Весь отдел вышел на улицу, а на параде миньоны ИТ-отдела заняли места на сцене. По его словам, они выиграли приз. «Но лучше всего мне сказал один сотрудник: „Я работаю здесь уже 11 лет и никогда раньше не участвовал в параде Cirque du Soleil на Хэллоуин“. Речь шла о том, чтобы собрать ИТ-отдел вместе, показать, что мы принадлежим к нему, что мы можем организовать что-то веселое. Это придало уверенности в том, что мы можем сделать что-то для бизнеса».
Это улучшило отношение и со стороны бизнеса. «ИТ-специалисты теперь были на первом месте, а не просто как люди, которые могут сделать WiFi», — говорит Бисайлион. «Мы здесь, мы понимаем, и мы хотим быть частью этой культуры». Постепенно отношение к ИТ начало меняться в сторону того, что бизнес и ИТ лучше работают вместе. «Это не изменилось мгновенно», — говорит он. «Но это открыло дверь для построения отношений».
Также по теме:
- Руководство — бизнес-менеджеры — ИТ: проблемы взаимодействия
- Сочетание Cynefin и Swarming для лучшего управления инцидентами
- 8 лучших практик технической поддержки: советы специалистов
- Новости для жертв лучших практик
- 5 шагов для лучшего управления сервисами
Источник: cleverics.ru
Бизнес и ИТ: от поддержки к партнерству
Переход на сервисную модель управления дает современному бизнесу возможность использовать ИТ не только в качестве инструмента операционной деятельности, но и как средство развития.
Ирина Малиновская, главный специалист дирекции ИТ-консалтинга компании «Сибинтек», член itSMF Россия
Переход на сервисную модель управления дает современному бизнесу возможность использовать ИТ не только в качестве инструмента операционной деятельности, но и как средство развития.
Распространенная народная мудрость «на ошибках учатся» не обходится без практичного соображения о том, что лучше всего учиться на чужих ошибках. Первопроходцы, конечно, такой возможности лишены. Но вот у тех, кто по какой-либо причине взялся за дело позже других, появляется шанс минимизировать ошибки новаторства и сократить путь к успеху. Однако внедрять результаты чужого опыта в собственную производственную деятельность — дело тоже не простое и чреватое существенными потерями.
Риски использования чужого опыта в основном связаны с недостаточным вниманием к внешним факторам. Во-первых, вполне возможно, что успех был достигнут благодаря некоторым особым условиям, которые просто не учитываются или на первый взгляд не имеют к полученному результату прямого отношения. Во-вторых, попытке повторить успех могут помешать некие условия, влиянию которых ранее накопленный опыт не был подвержен.
И как быть российским ИТ-подразделениям, которым зарубежные первопроходцы, имея в виду собственный опыт, рекомендуют позиционировать себя как провайдера услуг для своих же коммерческих и некоммерческих организаций, условно объединяемых здесь названием «бизнес»? Пригодны ли пути, которые описаны в лучших практиках, в наших условиях и при современных темпах изменений как в технологиях, так в бизнесе? Как сократить путь к успеху?
Чтобы найти ответы на эти вопросы, прежде всего следует разобраться в том, что же стоит за термином «лучшая практика».
Что такое лучшая практика
Иначе говоря, предполагается, что автор или владелец лучшей практики знает ответы на вопросы, что и как надо сделать для достижения определенной цели. Для того чтобы это знание можно было считать лучшей практикой, нужно еще как минимум описание, обеспечивающее возможность повторения опыта, и указание области применения.
Прямых указаний к действиям лучшая практика, как правило, не содержит, предлагаемые способы могут быть многовариантными. Решение о том, что и как из рекомендуемого должно быть сделано в каждом конкретном случае, необходимо принимать самостоятельно, а внедряются результаты собственных разработок. Наличие лучшей практики минимизирует принципиальные ошибки и упрощает изучение успешных решений, а адекватное ее применение существенно снижает риски использования чужого опыта. Отметим, что внедрение отдельных элементов из числа описанных лучшей практикой только потому, что эта практика «лучшая», может привести к обратному результату.
Передовой опыт, интересный для ИТ-подразделений, изложен в нескольких библиотеках. Каждая из них содержит свою лучшую практику и по сути отражает опыт взаимодействия разных категорий ИТ-специалистов с бизнесом применительно к специфике организационной структуры последнего. Наиболее распространенная лучшая практика для ИТ-специалистов — это, бесспорно, ITIL.
Библиотека ИТ-инфраструктуры (IT Infrastructure Library), цель которой формулируется как описание принципов эффективного и рентабельного использования ИТ-ресурсов, была создана в 80-х годах прошлого столетия и адресована сотрудникам министерств и других государственных учреждений Великобритании. Первая версия ITIL содержала более 40 книг. Вобрав в себя приемы, использовавшиеся задолго до появления термина «информационные технологии», для достижения различных целей в различных областях, ITIL v.1 выполнила, вероятно, самое главное назначение лучшей практики — создала основу для развития накопленного опыта в новых условиях и для достижения новых целей. На основе ITIL было создано множество новых лучших практик, но и сама она претерпела существенные изменения.
ITIL и предоставление услуг
По-настоящему популярной стала вторая версия ITIL, ядро которой составляют две книги, посвященные предоставлению и поддержке ИТ-услуг. Основная цель — более эффективное использование ИТ-ресурсов — осталась прежней, но годы работы, направленной на достижение этой цели, показали, что низкий уровень возврата инвестиций в дорогостоящие ИТ-ресурсы чаще всего бывает вызван непониманием потребностей основного бизнеса со стороны ИТ и возможностей ИТ-подразделений — со стороны бизнеса. Лучшей оказалась практика взаимодействия между ИТ и бизнесом, построенная на основе сервисной модели, независимо от специфики организационной структуры основного бизнеса.
Для термина IT service в версии ITIL v.2 допускались разные значения: от вполне конкретного, понятного бизнесу и обладающего измеряемыми параметрами качества, до некого общего «обслуживания», качество которого можно оценивать временем перерывов в работе пользователей, вызванных невозможностью использования технических средств. В странах с развитой культурой и широкой практикой предоставления услуг не надо было объяснять, что успех процесса предоставления и потребления услуги зависит как от поставщика, так и от потребителя. ИТ-подразделения приступили к описанию и согласованию с бизнесом потребительских свойств и требуемых параметров предоставления услуг, создаваемых на основе собственной производственной деятельности. Таким образом были созданы формат общения с бизнесом и критерии для оптимизации технических решений с прикладной точки зрения.
В развитых странах к моменту появления ITIL v.2 сервисный подход к взаимодействию с клиентами и партнерами был знаком бизнесу уже давно. Большинство компаний было готово воспринимать свое внутреннее ИТ-подразделение как сервисное, а соглашение об уровне услуги (SLA) — как средство контроля за расходами на ИТ.
Третья версия ITIL появилась в мае прошлого года. Подход к определению термина IT service стал в ней существенно строже. Сохранив и адаптировав к современным условиям приемы управления, входившие в предыдущие версии, ITIL v.3 укрепила позиции сервисной модели для управления в сфере ИТ и не обошла вниманием рост ее популярности в управлении бизнесом и программировании.
На пике интереса к сервисно-ориентированной архитектуре (SOA) новая версия ITIL в книге, посвященной разработке ИТ-услуг (Service Design), рекомендует везде, где возможно, использовать SOA и сходные принципы разработки. Все рекомендации ITIL v.3 относятся к управлению услугами. Они сгруппированы по фазам жизненного цикла — от выбора стратегии создания ИТ-услуги до непрерывного совершенствования услуг, предоставляемых пользователям.
Таким образом, действующая ныне версия ITIL дает ИТ-специалистам знания, необходимые для взаимодействия с основным бизнесом и создателями ИТ, каковыми являются архитекторы SOA. Это лучшая практика повышения эффективности использования ИТ-ресурсов для условий, предполагающих широкое распространение сервисного подхода.
SOA — использование сервисов
Программная архитектура, позволяющая с троить прикладные системы из независимых программных модулей (сервисов), появилась более 20 лет назад. Но само по себе ее применение не даст всех тех преимуществ, которые так щедро обещают сейчас производители. Для того чтобы современная идея SOA была реализована и принесла максимальную выгоду, прежде всего нужно, чтобы бизнес принял в качестве концепции своего построения и развития интеграцию бизнес-операций как взаимосвязанных услуг. Только тогда грамотные архитекторы SOA смогут обеспечить бизнесу возможность «быстрого реагирования» (business agility) без потери уже сделанных инвестиций и минимизировать затраты на ИТ, связанные с необходимостью частых реорганизаций. Заложенные архитекторами возможности могут быть реализованы в операционной деятельности пользователей при соответствующей поддержке ИТ-инфраструктуры, имеющей SOA-специфику.
Возникший за рубежом в последние годы интерес бизнеса к SOA, по данным аналитиков и экономистов, основан на потребности в новых конкурентных преимуществах в условиях изменившегося рынка. Сервисная ориентация позволяет организовать работу подразделений компании, ее партнеров, поставщиков и клиентов по принципу предоставления и потребления услуг. Таким образом, обеспечивается простота слияния и деления компаний, организации временных объединений и выполнения совместных проектов. SOA, в свою очередь, обеспечивает прозрачную автоматизацию для такой структуры. Кроме того, SOA предоставляет бизнесу методологию изменения традиционных бизнес-моделей и интеграции унаследованных приложений.
События последнего времени дают все меньше и меньше оснований воспринимать SOA как кратковременное модное течение или маркетинговый прием. О своей поддержке SOA объявляют не только такие лидеры рынка, как IBM, HP и Microsoft, — список этот постоянно растет. Казалось бы, далекая от прикладного ПО, компания Cisco тоже объявила о подготовке решения, направленного на поддержку SOA.
ИТ-подразделениям, которые используют сервисный подход в соответствии с лучшей практикой, изложенной в ITIL v.3, SOA дает возможность включиться в цепочку предоставления услуг и стать полноценным участником основного бизнеса. Все это опять-таки справедливо для условий, предполагающих хорошее понимание специфики сервисного подхода.
Проблемы сервисного подхода в мире и в России
Конечно, развитие SOA за рубежом тоже сопровождается проблемами. Многие западные аналитики и архитекторы SOA обращают внимание на необходимость взаимосвязанного развития SOA и ITIL, предвидя трудности мониторинга композитных приложений и поддержки усложнившейся ИТ-инфраструктуры. Управляющий директор компании THINKstrategies Джефф Каплан предупреждает, что, несмотря на общие цели и руководящие принципы ITIL и SOA, а также очевидные пути интеграции этих двух областей знаний, мало кому удалось создать согласованное решение — слишком долго специалисты работали в изоляции друг от друга.
В России пока преобладают другие проблемы. Еще в 2006 г . было отмечено существенное отставание как теоретического обоснования концепции SOA, так и практической реализации модели сервисно-ориентированного бизнеса в России. С того времени идеи SOA в нашей стране получили некоторую известность, но сервисно-ориентированный анализ и моделирование бизнеса, а также принципы разработки сервисов — вопросы, горячо обсуждавшиеся в это время зарубежными специалистами, — по-прежнему остаются в тени.
Знания основ ITSM (управления ИТ-услугами), полученные российскими ИТ-специалистами, благодаря популярности ITIL за рубежом в основном находят применение в сервисных компаниях. Руководство компаний, деятельность которых не связана с предоставлением услуг клиентам, зачастую считает управление ИТ-услугами делом, целиком относящимся к зоне ответственности ИТ. В таких случаях информация, необходимая для описания услуг и создания системы управления ими, в ИТ-подразделения не поступает. Использование рекомендаций ITIL ограничивается внедрением процессного управления, что тоже дает положительные результаты, но отнюдь не те, о которых идет речь в ITIL v.3.
Является ли слабая готовность российского бизнеса к использованию сервисной модели той причиной, по которой ИТ-подразделениям следует поискать себе другую лучшую практику, а программистам — подождать с освоением SOA?
Если зарубежные аналитики правы в своих оценках изменений рынка и интерес к сервисной ориентации у бизнеса не случаен, то конечно же нет. Противостоять обоснованной мировой тенденции в условиях глобализации вряд ли возможно, следовательно, российскому бизнесу придется принять сервисную модель управления, и тогда готовность ИТ-подразделений и программистов окажется весьма востребованной.
Информированы — значит вооружены
Итак, российские ИТ-специалисты вооружены лучшей практикой и знанием того, что условия, необходимые для ее успешного применения, в России в большинстве случаев отсутствуют, а та программная архитектура, на которую она рекомендует опираться, не развита. Имеются также сведения об ошибках, сделанных первопроходцами: не должны ITIL и SOA развиваться независимо друг от друга. Кроме того, есть все основания полагать, что российский бизнес в той или иной степени будет вынужден использовать организационные принципы, принятые зарубежными партнерами.
Так что же делать российским ИТ-специалистам в быстро изменяющихся условиях современного рынка?
«Все, что изменяется, может быть сделано лучше, если оно основано на SOA» — такое высказывание взял Андрей Коптелов, эксперт компании «IDS Scheer Россия и страны СНГ», эпиграфом к своей статье, где он перечисляет «первые шаги к SOA». Конечно, среди перечисленных шагов нет указания привлечь к работе сотрудника ИТ-подразделения — специалиста по ITSM, знакомого с рекомендациями ITIL v.3 по управлению жизненным циклом услуги. Но если добавить к списку такой шаг, можно будет решить сразу несколько проблем.
Во-первых, первые шаги к SOA будут сделаны не только заказчиками и разработчиками ИТ, но и теми, кому придется обеспечивать готовность изменившейся ИТ-инфраструктуры и в конечном счете самое главное — непрерывность бизнеса.
Во-вторых, SOA-инициативы будут поддержаны средствами и методами, собранными в ITIL и, по мнению зарубежных коллег, вполне пригодными для организации управления SOA (SOA governance).
В-третьих, ИТ-подразделение сможет начать реальное взаимодействие с бизнесом по описанию ИТ-услуг во взаимоувязке с определением SOA-сервисов.
Таким образом, распространение SOA в России будет способствовать не только развитию отечественного бизнеса, но и созданию условий, благоприятствующих успешному применению лучшей мировой практики управления в сфере ИТ. Адекватное использование рекомендаций ITIL v.3 избавит российских ИТ-специалистов от излишних трудностей и обеспечит соответствие международным стандартам.
Но главное даже не это. Современному бизнесу необходимо использовать ИТ не только в качестве надежного и эффективного инструмента операционной деятельности, но и как средство развития. Применение сервисной модели при управлении как ИТ, так и бизнесом в целом, дает такую возможность. Совместные усилия специалистов по SOA и ITIL v.3 способны обеспечить России, взявшейся за дело позже других, реальный шанс достичь успеха более коротким путем.
Варианты взаимосвязанного использования ITIL и SOA во благо российского бизнеса могут быть разными. Здесь еще многое предстоит сделать, а пока лишь совершенно ясно, чего делать не надо. Не надо подходить к использованию лучшей практики или новой программной архитектуры формально. Не надо увлекаться внедрением процессов управления ИТ-услугами, не определив объекта управления.
Не надо выдавать внедрение отдельных элементов SOA на уровне операционной деятельности за переход к новой программной архитектуре. Это только осложнит без того непростую ситуацию.
Источник: ecm-journal.ru
Мальтийский крест взаимоотношений ИТ и бизнеса
«Взаимное непонимание — самая подходящая основа для брака» — это высказывание Оскара Уайльда достаточно точно отражает парадоксальную ситуацию во взаимоотношениях представителей бизнес- и ИТ-подразделений большинства компаний.
Вам не удастся что-либо изменить, фиксируя существующую реальность. Чтобы что-либо изменить, постройте новую модель, которая сделает существующую модель бесполезной.
Ричард Бакминстер Фуллер «Взаимное непонимание — самая подходящая основа для брака» — это высказывание Оскара Уайльда достаточно точно отражает парадоксальную ситуацию во взаимоотношениях представителей бизнес- и ИТ-подразделений большинства компаний, в которых мне довелось работать или как внешнему консультанту, или как наемному ИТ-менеджеру. Наиболее ярко этот парадокс проявляется в ходе внедрения, эксплуатации и модернизации информационных систем (ИС или бизнес-приложений), и в первую очередь при решении вопросов по изменению /модернизации ИС.
Позиция бизнеса в данном случае достаточно проста и понятна: «Развитие бизнеса и ситуации на рынке требует постоянных изменений, и мы не можем ждать, пока вы все это сделаете и оттестируете в «вашей» системе. Расходы на ИТ непрозрачны, и мы не понимаем, на что вы тратите деньги, которые мы зарабатываем для компании…» Но позиция ИТ также обоснована и логична: «Бизнес-приложения будут функционировать стабильно, если в них вносить только действительно необходимые изменения, оттестированные ключевыми пользователями согласно стандартным процедурам.
Модернизация и новые технологии требуют существенных инвестиций при ограниченных ресурсах ИТ-подразделений…» При этом обе стороны прекрасно понимают, что быстрые изменения становятся объективной реальностью, с которой мы сталкиваемся ежедневно. И. которых бизнес порой просто не замечает за рутиной ежедневных дел и о которых ИТ-специалисты узнают слишком поздно, когда очередное, написанное на коленке требование, должно было быть реализовано «уже вчера», а вы (ИТ) сами знаете «вашу» систему.
В итоге подобных неструктурированных изменений полученные результаты, могут не в полной мере удовлетворить как внутреннего клиента, так и ИТ-специалистов, задействованных в выполнении запроса. Это приводит к недопониманию и стрессам во взаимоотношениях представителей бизнес- и ИТ-подразделений.
И чтобы найти способ минимизировать потенциальные конфликты и их последствия и построить модель, обеспечивающую гармоническое взаимодействие, попробуем ответить на несколько вопросов: · Кто является владельцем информационной системы (бизнес-приложения) и кто определяет, что нужно/можно в ней изменить и как нужно/можно изменить? · Чем обоснован конкретный запрос на изменение или проект и как он влияет на другие процессы и бизнес-приложения? · Как должно быть организовано управление изменениями с учетом обеспечения выполняемых бизнес-операций, принципов управления процессами (бизнес-технологий), требований управления бизнес-приложениями и их функциональных возможностей (ИС/ИТ), правил управления проектами модернизации информационных систем (проектных технологий)? Не могу сказать, что это единственные вопросы, на которые нужно ответить, но они представляются наиболее актуальными для рассмотрения сложной системы взаимоотношений (для простоты восприятия она показана в виде гиперсферического октаэдра[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) они обозначены трехбуквенными аббревиатурами ролей. Тактические вопросы по каждой из групп решают руководители и специалисты, чьи роли обозначены двух- и трехбуквенными аббревиатурами (например, ВБП – ВИС – КП для группы бизнес-операций). Представленная модель — это лишь один из вариантов оптимизации взаимодействия ИТ и бизнеса, и, несомненно, другие модели сотрудничества также имеют право на жизнь. К сожалению, объем журнальной статьи не позволяет прописать эти схемы, равно как и каждую роль в группах модели мальтийского креста, связи между данными ролями и основные показатели эффективности их деятельности.
Источник: www.it-world.ru