Управление процессами компании: бизнес и ИТ

Привет, Хабр! Меня зовут Андрей Прокофьев-Нужный АндрейВ продолжении темы, связанной с внедрением Каталога ИТ-услуг в компании, хочу разобрать достаточно популярный вопрос (не знаю, как у других, но у нас так точно) – зачем нужно возиться с услугами, если все пользователи работают с системами? Логичнее же «идти от систем», чем каких-то «никому не понятных услуг». Давайте разбираться и взвешивать все «за» и «против». Пусть каждый сам для себя решит, как эффективно выстроить процесс управления ИТ в общем и, взаимодействие с бизнесом, в частности.

Я делюсь своим опытом работы в одной из крупных экосистемных компаний России, главные бизнесы которой ритейл и оказание различных сервисных услуг. Поэтому проблема эффективного взаимодействия ИТ и бизнеса для нас является актуальной. Несколько лет назад у нас в компании произошла продуктово-сервисная трансформация, чтобы бизнес и ИТ работали в одной команде. Продуктовые команды включают в себя как представителей ИТ, так и бизнеса. Каждая команда управляется тимлидом. Команды объединяются в продукты или платформы. Продукты и платформы, в свою очередь, объединяются в домены. Каждым доменом управляет технический руководитель (Chief Technology Officer) и продуктовый руководитель (Chief Product Officer). Следовательно, и трансформация Каталога, содержащего услуги и системы, заключалась в их перераспределении между всеми доменами. Структурно услуги следовало отнести к продуктам, а системы – к платформам. Вроде все понятно, но на практике такое упражнение вызвало трудности у коллег, как мне кажется, именно из-за услуг - чего-то непонятного, сложного, бессмысленного и беспощадного. С моей точки зрения, ключевым объектом управления все-таки должна стать именно услуга, а не система.

Уж сколько раз твердили миру

Если с понятием системы все более-менее понятно в этом мире, то с понятием услуги не так все однозначно. К тому же здесь нужно учитывать, что непосредственное отношение к услугам имеют самые разносторонние сотрудники компании. Не все читали или изучали ITIL, ISO20000 и потому, общаясь с коллегами «на птичьем языке», не можешь ожидать от них однозначного понимания.

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

Из причин:

·       разные графики. Из 160 приглашённых, к встрече подключается порядка 30-40 человек;

·       цейтнот. «Выливая на людей» большой объём информации за короткий промежуток времени, жди что «твёрдо» усвоится только 30% материала, при том изложенного в первые 15 минут. К сожалению, это свойство человеческого мозга. При этом люди во время встречи должны вовлечённо изучать ваш материал, а не заниматься своими делами, попутно поглощая пищу;

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

·       текучка кадров. Кто-то же должен погружать новых людей в глубины всех миров (бизнесов). Как это делать, когда и каким образом – сложный вопрос для большой компании.

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

Что есть услуга

Для сравнения я приведу несколько определений, чтобы сложилось наиболее полное представление. Вот такое определение услуги даёт ITIL:

Услуга (service) – способ обеспечения совместного создания ценности (value) через содействие заказчикам в получении конечных результатов, которых заказчики хотят достичь, без необходимости для заказчика управлять специфическими затратами и рисками.

А вот так услуга определена в стандарте ISO9000:

Услуга – это результат, как минимум, одного действия, обязательно произведённого (осуществлённого при взаимодействии) между поставщиком и заказчиком (потребителем), как правило, нематериальный.

В нашем процессе управления Каталогом услуг мы определили услугу как:

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

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

Надо понимать всю глубину наших глубин

Итак, имеем в наличии ИТ-подразделение, поддерживающее автоматизацию бизнес-процессов через администрирование информационных систем. Схематично объекты нашего процесса:

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

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

Вот пример другого бизнес-процесса, у которого была определена только одна услуга и система:

Услуги могут быть детализированы и до уровня бизнес-операций. Предложение услуги или, другими словами, «форма заявки» размещаются на пользовательском портале компании. Каждая из форм заявок использует в качестве классификатора услугу и систему, как обязательный атрибут заявки. Если вы решились дробить услуги на бизнес-операции, значит в качестве классификаторов у инцидентов и запросов будут бизнес-операции и системы, а услуги переместятся выше – на уровень агрегации. Лучше не использовать вперемешку и услуги, и бизнес-операции в качестве классификаторов, т.к. потом вы не сможете разделить статистику по этим объектам управления.

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

Почему не системы

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

Любые договорённости должны быть документально зафиксированы и для этого объекта тоже есть свой термин – SLA (Service Level Agreement). Соглашение об уровне сервиса, иными словами. Теперь представьте, что бизнес для своих бизнес-процессов хочет разные условия поддержки и готов это финансировать. Например, часть процессов должна поддерживаться круглосуточно, т.е. 24х7, часть – календарную неделю, т.е. 8х7 и остальные – обычную рабочую неделю, т.е. 8х5. ИТ готов выполнить эти требования, остаётся дело за малым – распределить их по своим системам, которые обеспечивают работу бизнес-процессов. Возьмём простой пример – SAP ERP, обеспечивающий работу логистических, финансовых, договорных бизнес-процессов. Если представить схематично, то выглядит это так:

При таком подходе возникнет ряд проблем. Проблема первая – сможет ли владелец системы SAP ERP обеспечить SLA с такими требованиями одновременно? Например, при регистрации заявки по системе SAP ERP, какой из нижеперечисленных SLA должен быть ей присвоен, если в качестве классификатора вы используете только систему?

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

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

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

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

Трансформация сознания

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

1.       Единый ИТСМ-портал

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

·       Регламент

·       Ролевые инструкции участников процесса

·       Отчётность по процессу

·       Предложения по улучшению процесса

·       Методики

·       Демонстрационные и учебные материалы

·       Руководства пользователя

·       Протоколы встреч

Понятно, что для разных процессов перечень разделов может различаться. Главное, чтобы названия основных разделов совпадали, тогда людям проще будет в них ориентироваться. У нас такой портал размещён в Confluence. Инструмент прост и удобен в использовании, как администратором пространства, так и коллегами.

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

2.        Регулярные online-встречи по процессному управлению

Мы у себя в ИТ организовали еженедельные часовые встречи в online по любым вопросам и проблемам процессного управления. В календаре Outlook эти повторяющиеся встречи так и назывались – «Еженедельные встречи по процессному управлению ИТ (инцидент менеджмент, управление каталогом услуг, проблем менеджмент, управления событиями, управления знаниями и т.д.)». Состав встреч постоянный или расширяющийся, включающий в себя владельцев услуг и систем, менеджеров групп техподдержки и тимлидов, владельцев продуктов и других сотрудников, желающих приобщиться к доброму, светлому, вечному. В итоге приглашённых набралось порядка 160 человек. Понятно, что на встречи приходили лишь те, кому повестка была актуальна или интересна. Повестка рассылалась заранее, поэтому у ведущего была, как минимум, неделя на подготовку своего вопроса или темы. Вопросы компоновались с расчётом на общий тайминг встречи. Если за неделю повестка не набиралась, то встреча отменялась. При необходимости велась запись и затем выкладывалась на общий ресурс. Еженедельные встречи мы использовали и для информирования участников процессов о всех новинках или изменениях в «правилах игры», автоматизациях наших процессов, планах развития и т.п. Насколько эффективна такая практика для компании в целом, я оценить не могу, но для тех, кто отвечает за поддержку пользователей и работает с заявками, такие встречи были востребованы. Важно отметить, что на встречи приглашались и представители бизнеса как непосредственные участники процесса.

3.        Разноплановая и простая отчётность по процессам

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

Прежде, чем разработать отчёт, его следует классифицировать:

по назначению

·       аналитический

·       оперативный

по потребителю (или роли)

·       руководство ИТ

·       менеджер процесса

·       владелец услуги/системы/продукта

·       менеджер группы поддержки/тимлид

·       подрядчик/поставщик

·       …

Далее, определить, какие показатели/метрики этот отчёт должен отображать, а также выгружаемые данные.

И самое важное, на мой взгляд, – выбрать инструмент визуализации отчёта. Мы нашли очень прекрасный вариант из числа систем класса process mining или, другими словами, систем процессной аналитики. Про эту историю вы также можете почитать на хабре, которая описана в статье Process Mining: почему пилотный проект хорошо проводить на базе ИТ-подразделения. Во-первых, система имеет встроенные коннекторы для подключения ко всем популярным системам, во-вторых, она достаточно проста в освоении на уровне аналитика и пользователя. У нас в компании, например, поддержку работы этой системы, обновление данных в ней, разработку отчётов и всё-всё-всё по этой системе делает один сотрудник, остальные только пользуются результатом – «ходят» в систему, чтобы смотреть свои отчёты. В-третьих, как инструмент оперативного контроля, лучше не придумаешь. Благодаря гибкой системе фильтров, дашборды меняются в режиме online. Конечно, целевое использование этой системы шире, чем процессы ИТСМ – это анализ бизнес-процессов компании, ориентированный на выявление неэффективностей и снижение финансовых потерь в реальном времени. Но, прежде чем «продать» её бизнесу, мы настроили в ней модели и отчёты для 2 процессов ИТСМ – инцидент-менеджмента и процесса управления запросами и используем их как в повседневной работе, так и для демонстрации возможностей системы.

Пример одного из нескольких десятков дашбордов:

Все дашборды, понятно, настроены в соответствии с требованиями процесса, на основании сформированной сервисно-ресурсной модели и используют объекты Каталога услуг. Поэтому коллегам просто в них ориентироваться, т.к. они видят знакомые им названия. А, благодаря инкрементальному обновлению данных, любые изменения в Каталоге услуг и CMDB практически сразу отображаются в системе отчётности. Это удобно, если вам требуется ежедневный контроль – открыл ссылку и посмотрел, если надо, выгрузил и сохранил. Красота, одним словом. Про табличные отчёты не говорю, т.к. они здесь тоже есть, как и в любой другой системе отчётности.

Услуги vs системы

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

Спасибо всем, кто прочитал до конца. Буду благодарен комментариям и мыслям