Предпосылки создания российской методологии
Мы пришли к пониманию, что нам нужен собственный российский ITIL, в том числе потому, что нельзя просто взять, напрямую переписать ITIL в регламенты организации и сказать, что теперь нас ждет счастье. Так это не работает. Мы не будем жить по-новому, у нас не появятся бизнес-процессы, они не будут выполнять свои функции, и у нас не наступит вселенское качество информационных услуг только потому, что мы перенесли текст лучших практик к себе в регламенты.
Есть еще одна предпосылка, которая привела нас к идее создания российской методологии. Три года назад у нас появилась новая реальность, в которой пришлось жить. Западные технологии сняли нас с технической поддержки, а затем компании начали отзывать свои сертификаты.
По Scrum начали отзывать сертификаты и говорить: «Ребята, забудьте то, что вы знали, забудьте, чему вы учились и что сдавали. Ваши знания вам не принадлежат, верните наши сертификаты». Так происходило во многих областях. Сертификаты отменяли, запрещали проходить обучение, сдавать экзамены на сертификаты, подтверждать свои знания, умения и навыки и дальше работать с подтверждением того, что вы действительно являетесь специалистом.
Это стало серьезной проблемой при найме специалистов. В команду приходит человек и говорит: «Я умею делать вот это, вот это и вот это». При этом опыт остается неподтвержденным. Человек мог быть в проекте, но участвовать в нем в роли младшего исполнителя и не вносить значимого вклада. Возникает вопрос, как это проверять.
Любая компания начинает проводить тестирование, из-за чего цикл найма, подбора и адаптации специалиста сильно увеличивается. В тот период рынок был рынком кандидата, и три года назад было крайне сложно найти адекватного специалиста. Многие уехали, приходилось выбирать из тех, кто остался.
Ушли методологии, ушли сертификаты, ушли рейтинговые агентства. Компании вроде Gartner и Forrester больше не могли говорить, что тот или иной программный продукт соответствует требованиям, и что его применение гарантированно приведет к достижению целей.
На те рейтинговые агентства, которые существуют сейчас в России, я бы не стал опираться. Ни один рейтинг, который я вижу, не позволяет адекватно определить, что программный продукт действительно умеет делать, а что не умеет. Это можно проверить только через личный опыт и внедрение.
Компании вроде PinkVerify и Forrester также ушли и оставили нас без поддержки.
Создание ассоциации и объединение экспертов для разработки РИТМ
В этой ситуации мы начали объединять коллег вокруг нашей ассоциации специалистов itSMF России. Это одна из немногих ассоциаций, которая довольно долго работала на международном рынке – практически до конца прошлого года. В какой-то момент нам прямо написали письмо с просьбой больше не приходить на встречи и сообщили, что взаимодействие невозможно. Недавно снова пришло приглашение на совещание – мир меняется, и хорошо, что он меняется к лучшему.
Мы разработали методологию и ее оформление. На дату публикации этой статьи вокруг нее объединились уже 150 авторов, и это число продолжает расти. Если раньше речь шла о 27 компаниях, то сейчас в разработке участвуют уже 50 российских компаний, а также компании из дружественных стран.
Мы сформировали структуру методологии, очертили ее рамки и запустили в работу экспертов, чтобы они поделились своим опытом, договорились между собой и описали референтную модель, более детальную, чем TOGAF, ITIL, DAMA-DMBOK и другие.
Мы не отменяем существующие методологии и не говорим, что они плохие только потому, что они зарубежные. Мы не собираемся их искоренять или менять терминологию. Мы остаемся в том же рациональном русле и устраняем пробелы между методологиями.
Например, информационные технологии и информационная безопасность живут не в самых дружелюбных отношениях. Одни контролируют других, при этом управляют одними и теми же объектами. Им необходимо взаимодействовать между собой и выстраивать совместную работу.
Поэтому тот же NIST – одна из немногих в мире методологий управления информационной безопасностью – полезна, но не дотягивает до задачи интеграции требований регуляторов. У нас есть требования ФСТЭК, ФСБ, в банковском секторе – положения регуляторов в лице Центрального Банка, в промышленности – требования Минпромторга, Ростехнадзора и другие документы, которые насаждают свои процессы и правила. Эти требования необходимо перекладывать в методологию, но общей базы для этого нет.
Такая же ситуация существует в архитектуре и в данных, то же самое – в COBIT и в методологиях, которые занимаются анализом эффективности и аудитом. Все это относится к одним и тем же объектам инфраструктуры: к тем же каналам связи, тем же серверам, программному обеспечению. Мы управляем одним и тем же, просто называем это по-разному. Где-то это сервисы, где-то услуги. Если начать объяснять это по-английски, то и там, и там используется delivery, и в обоих случаях присутствует слово service. Там к этому подошли рационально, споров нет.
Есть еще более сложный вопрос: чем отличаются ИТ-продукты от ИТ-услуг, это одно и то же или разные сущности. Эти холивары мы хотим устранить и перейти в конструктивное русло.
Понятно, что кому-то удобно называть сервисы сервисами, а услуги услугами, кто-то использует термин «сервисные услуги». Есть подход, при котором сервисные услуги и сервисное обслуживание считаются особенностями языка.
Если разбираться в объектах управления, становится понятно, что управляем мы оборудованием и программным обеспечением. На их основе формируется логическая структура, которая предоставляется конечному заказчику. Это может быть доступ в интернет, обеспечение коммуникациями, мессенджеры, доски Miro, почта и все остальное. Все это относится к коммуникациям и подается как единый сервис, который обслуживают одни и те же ИТ-специалисты.
При анализе каталогов услуг внутри компаний часто видны 150 позиций, за которыми стоят одни и те же люди, выполняющие одну и ту же работу. Возникает вопрос, зачем так дробить. Если задача каталога услуг – структурировать работу, направлять запросы и как можно быстрее доводить информацию до исполнителя, то в этом и заключается его смысл, а не в сотне услуг, которыми формально управляют.
Представление модели РИТМ и значение ее названия
Мы разработали модель методологического описания всех бизнес-процессов, которые присутствуют при управлении информационными технологиями. Эту модель мы назвали РИТМ. В название заложен смысл рациональной модели, которая не ограничивается только Россией. Через страны БРИКС и через Россотрудничество эта методология уже распространяется, работа в этом направлении ведется.
Культурные атташе и представители российских домов в дружественных странах уже знают, что такое РИТМ, и рассказывают местному бизнесу о том, что существует методология, которая рационально подходит к управлению информационными технологиями. РИТМ – это российская рациональная ИТ-модель, методология и менеджмент.
Само слово «ритм» в своем корне несет смысл синхронизации, движения в одном стиле и в одном темпе. Один из ключевых эффектов создания методологии – договоренность между участниками. Появляется единый глоссарий и единая терминология, одни и те же вещи называются одинаково.
В результате специалист из компании, где используются сервисные услуги, приходит в компанию, где используются продукты и услуги, и не теряется. Он быстрее адаптируется, понимает применяемую терминологию и быстрее включается в работу. Это ускоряет адаптацию специалиста в новых условиях.
Цели РИТМ: эффективность и устранение транзакционных издержек
РИТМ направлен на повышение эффективности системы управления информационными технологиями в современных условиях. Бизнес-процессы ускоряются, темпы изменений нарастают. Уже не существует организаций, которые не управляют изменениями и у которых нет потока проектов по внедрению нового.
Если обращаться к истокам управленческой экономики, становится понятно, почему в названии методологии появилось слово «ритм». Мы подробно разбирали его значение и пришли к общему пониманию, зачем оно необходимо и почему методология должна называться именно так.
Существует несколько видов издержек. Есть прямые издержки производства. Чтобы произвести товар или услугу, необходимо понести определенные затраты: электричество, оборудование, ресурсы, которые требуются, например, для производства партии пластиковых изделий. Но существуют и транзакционные издержки. За доказательство их существования Рональд Коуз получил Нобелевскую премию.
Чтобы произвести пластик, необходимо добыть нефть, транспортировать ее в перерабатывающую компанию, получить полимеры, разместить их на складе и передать в производство. Это издержки взаимодействия между людьми, издержки доказательства прав собственности и другие сопутствующие издержки.
Существуют также издержки оппортунистического поведения, которые возникают при внедрении новых правил и регламентов. Мы пишем регламенты, но сталкиваемся с тем, что новые правила не принимаются в сложившихся коллективах, потому что люди привыкли работать по-другому. Возникает сопротивление, агрессия, отрицание, затем принятие и присоединение. Это естественная часть жизни организаций.
РИТМ направлен на выстраивание четкой и эффективной системы управления взаимодействием между ИТ и не-ИТ. Таким образом, мы целимся в снижение транзакционных издержек. В промышленности за четыре промышленные революции порядок в производстве уже во многом наведен, и дальнейшие изменения не дают такого эффекта. Существенный эффект можно получить, если навести порядок именно в системе управления.
Принцип соответствия сложности системы управления объекту управления
Сложные объекты не могут эффективно управляться простыми системами. Система управления должна соответствовать объекту управления по сложности, масштабам и объемам. Этот принцип является одним из постулатов РИТМ.
Существуют небольшие компании и крупные предприятия, и в тех, и в других есть информационные технологии. При этом степень сложности, неопределенности и запутанности у них различается, а значит, и подходы к управлению должны быть разными. Это не учитывается в существующих методологиях.
Мы часто забываем про культурные слои, про сложившийся образ жизни компаний, про особенности управления информационными технологиями на разных этапах их развития. Мы забываем, что существуют простые и сложные системы, которым требуются разные системы управления. Эти системы могут меняться местами в условиях турбулентности, когда резко меняется внешняя среда.
Мы живем в условиях постоянных изменений и должны адаптироваться к ним. Слово Agile изначально означает адаптивность. Исторически термин Agile был выбран при создании манифеста в 2001 году, поскольку слово adaptive уже использовалось в названии книги одного из авторов, и его применение создавало бы конфликт интересов и некоторые коллизии с авторскими правами.
Структура РИТМ: области управления
Ключевой состав свода знаний:
-
РИТМ.Основы
-
РИТМ.Стратегия
-
РИТМ.Архитектура
-
РИТМ.Финансы
-
РИТМ.Услуги и Продукты
-
РИТМ. Производство продуктов и услуг
-
РИТМ.Активы
-
РИТМ.Надежность
-
РИТМ.Операции
-
РИТМ.Постоянное улучшение
-
РИТМ.Автоматизация
-
Глоссарий
РИТМ – это совокупность методологий, бизнес-процессов и описаний, которые создаются совместно с различными авторами. Он разделен на области управления. В основе лежит базовое описание того, что необходимо для управления информационными технологиями. Далее следуют области стратегического, тактического и оперативного управления, а также непрерывного совершенствования.
В методологию включено управление финансами. Это нетипичная область для ИТ, поскольку специалисты в ИТ обычно не являются финансистами. При этом умение рассчитывать совокупную стоимость владения, учитывать ее во времени, строить прогнозы эксплуатации является необходимым элементом управления.
При использовании продуктового подхода через продукты и услуги требуется проверка гипотез ценности, формирование гипотез проблем и гипотез решений, проведение глубинных интервью. Этим занимаются специалисты по продукту, которые формируют бэклог и ставят задачи. ИТ-специалисты и продуктовые команды часто существуют параллельно, и эти два мира должны взаимодействовать.
В России давно известны подходы ITIL и ITSM, а продуктовый подход активно используется последние годы. При этом между ними существует несогласованность: продукт и услуга трактуются по-разному, что порождает постоянные споры. Эти вопросы также заложены в РИТМ.
Управление активами относится к управленческому учету. Оно включает учет основных средств и малоценных активов, понимание стадий их жизненного цикла до ввода в эксплуатацию, в процессе использования и при выводе из эксплуатации.
Здесь отдельным направлением работы является РИТМ.Автоматизация. У нас нет возможности опереться на базу знаний или референтную модель и сказать, что один продукт нам подходит, а другой не подходит, потому что он что-то не реализует или реализует не в полном объеме. Это можно сделать только через критерии, о которых необходимо договориться.
Те, кто сталкивался с построением сравнительных схем анализа систем и формированием критериев выбора решений, знают, откуда берется информация. Обычно анализируют функциональный состав, определяют реальные потребности и начинают проверять соответствие.
Я работал и со стороны интеграторов, и со стороны вендоров. В какой-то момент от крупной производственной компании я получил Excel-файл с критериями, затем этот же файл прислали в перевернутом виде, с теми же самыми параметрами. Я просто поменял местами строки и столбцы и предложил дальше не заниматься бесполезными упражнениями, попросил сразу пригласить меня на тендер, потому что в таком формате проработки тендера я участвовать дальше не готов. Меня исключили из финалистов, сказали, что я не подхожу.
Таких сравнительных таблиц очень много. Если критерии в них одинаковые – это хорошо. Но часто в них используются формулировки, под которые подходит практически любой программный продукт. Когда я работал на стороне заказчика в одном из крупных российских университетов, я делал то же самое. На старте у меня было 16 продуктов, и подрядчики говорили, что умеют делать все. При этом критерии были сформулированы так, что фактически сводились к формуле «должно быть». Как именно это реализовано, оставалось за рамками, у всех подрядчиков в ответах и было указано «должно быть».
Доступность материалов РИТМ и бесплатное распространение
РИТМ как основа, принципы описания процессной модели и рекомендации будут доступны бесплатно. Это осознанная цель. Именно поэтому вокруг методологии объединено так много авторов. Это коллективная работа, направленная на согласование единых подходов.
Подобные процессы уже проходили другие рынки. В свое время каждая компания разрабатывала собственные фреймворки: Microsoft – MOF, IBM – свою модель и так далее. Со временем все эти подходы начали пересекаться, и специалисты стали договариваться между собой. В итоге появились крупные краудсорсинговые модели, такие как «Википедия», где информация складывается, перепроверяется и развивается всем сообществом, таким образом информация принимается как своя всеми участниками.
Open source-лицензия принадлежит ассоциации, но распространяется свободно. Любой желающий может получить доступ к описанию всех областей управления, к сквозной ролевой модели или к ролям в отдельных областях, к пошаговому описанию бизнес-процессов, к перечню артефактов, необходимых для выполнения этих процессов: кто, что, когда делает, с помощью чего и над какими объектами выполняются операции, вплоть до объектов данных и их атрибутов.
Этим РИТМ отличается от существующих методологий. Мы идем вглубь и описываем кейсы, показывая, в какой момент и с какой степенью детализации модель стоит применять в конкретной компании.
Отдельный раздел посвящен скрытым деструктивным сценариям. Многие компании уже прошли путь построения систем управления и столкнулись с негативным опытом. Эти сценарии будут описаны, и коллеги охотно делятся такими кейсами. Это формат антиконференций, где говорят не об успехах, а о провалах. Выученные уроки имеют большое значение.
Сотовая (гексагональная) модель РИТМ
Методология РИТМ представлена в виде сотовой модели. Некоторые коллеги называют ее гексагональной. Эта структура возникла на основе представлений о многоуровневом управлении, которые встречаются в древних мифах Греции, Скандинавии, Древней Руси, где есть высшие уровни, средние уровни и базовый уровень, как например Явь, Правь и Навь.
В верхней части модели располагается корпоративное управление и стратегия. Здесь находятся области стратегического управления и контроля, а также связи между ними. Их расположение не случайно. В центре модели – операционная деятельность и основное производство. Это нервная система организации, без которой она не может функционировать. Здесь располагаются управление инцидентами, сервис-деск, управление запросами пользователей, каталог услуг и все процессы, связанные с основной деятельностью.
Верхний уровень отвечает за целеполагание, установление правил, governance, risk и compliance. Здесь же находится процессный офис, который задает требования к бизнес-процессам, управление проектами и управление организационными изменениями. Это область стратегии, управления и контроля.
Далее следует тактический уровень – уровень среднего менеджмента. Здесь располагается управление активами, теми объектами, которые участвуют в цепочке создания ценности и формируют ценность для заказчиков и внутренних клиентов.
Производственный уровень располагается напротив стратегического. Области управления балансируют друг друга. Правая сторона ориентирована на клиента, левая – на внутренние процессы и предотвращение рисков внешней среды. Поэтому управление архитектурой и надежностью располагаются напротив друг друга, так же как управление финансами и управление продуктами и услугами.
Таким образом формируется понимание, кто является заказчиком, какую ценность он получает, какие потребности закрываются, за счет каких финансовых ресурсов и с использованием каких активов. Активы проходят преобразование через потоки upstream и downstream при производстве продуктов и услуг.
Каждая область управления включает в себя отдельные практики и процессы, и может быть детализирована по принципу фрактальности, формируя собственную сотовую модель. В центре находится корпоративное управление ИТ. Для управления ИТ необходимы стратегия, непрерывное совершенствование, управление разработкой, операционные процессы, учет активов, надежность, архитектура и понимание финансовых ограничений и возможностей.
При дальнейшей декомпозиции, например в области управления архитектурой, формируется собственная фрактальная модель. В нее входят формирование архитектурного видения, архитектурный аудит, архитектурный надзор и исследование технологических решений. Это позволяет контролировать соответствие создаваемых продуктов и услуг архитектурным требованиям и проводить корректирующие мероприятия.
Таким образом, модель РИТМ позволяет двигаться от корпоративного управления к управлению ИТ и далее – к детализированным областям, таким как управление архитектурой и управление данными, которые в модели объединены между собой.
Структура описания областей управления и процессов
Для каждой области управления, на примере управления ИТ, мы разработали цели и задачи. Зачем нужна эта область, какие задачи она решает и какую ценность несет. Для каждой такой области определены свои ценности и указано, для кого они создаются. Сформирована карта стейкхолдеров. Понятно, для какого стейкхолдера или группы стейкхолдеров создается ценность в рамках конкретного процесса.
Это позволяет избежать ситуаций, с которыми я сталкивался раньше. Я пришел в компанию, проработал полгода, и мне задали вопрос: «А ты вообще зачем нужен компании? Что такое ITSM? Это люди в сервис-деске или нет?» Я отвечаю, что занимаюсь архитектурой системы управления. Возникает следующий вопрос: «Зачем, если есть архитектура прикладных систем и всего остального?» Предлагают объяснить владельцу компании, за что он платит деньги. В такие моменты становится очевидно, зачем нужна формализация ценности каждой области управления.
Каждая область управления делится на практики и процессы. Практики – это совокупность подходов, методов реализации чего-либо. Практики также могут включать в себя несколько процессов. Процессы имеют структурированное описание. Там, где процесс можно выделить и описать, мы делаем это по единому шаблону, с разных сторон. В общедоступной базе формата Документ как Код эти практики и процессы будут описаны именно в таком формате, который принят всеми авторами как единый стандарт.
Если процесса нет, а деятельность состоит из проектов, поручений и разовых активностей, применяются методики и практики. Мы описываем не только процессы, но и набор методик, которые используются для выполнения той или иной деятельности. Стратегия, например, не укладывается в процесс. Не существует процесса создания стратегии. Есть деятельность по формированию стратегии, которая выполняется периодически и позволяет оценивать текущее положение компании, целевые состояния и план перехода из точки А в точку Б. Кто участвует в этом процессе и как он выстраивается, также описывается.
Таким образом, РИТМ включает процессную часть, где процессы можно формализовать, и методологическую часть, представленную в виде методик и практик. В ITIL четвертой версии появились практики, но даже авторам этих практик бывает сложно четко объяснить различие между процессами и практиками. В РИТМ эти понятия разделены. Дано определение ИТ-практик и ИТ-процессов, и с этим подходом достигнуто общее согласие.
Примеры специализированных областей: надежность и информационная безопасность
Отдельный пример – РИТМ.Надежность. Существует SRE и связанные с ним подходы. В ITIL слово «надежность» встречается всего лишь несколько раз. При этом в российской инженерной школе надежность всегда находилась в центре внимания. Системы создаются с пониманием пределов их прочности и отказоустойчивости. Этот подход мы не хотим терять и сознательно интегрируем его в методологию.
В область надежности включены современные практики управления наблюдаемостью. Это развитие мониторинга, при котором каждая система должна предоставлять данные о своем состоянии и параметрах, позволяющих делать выводы о работоспособности. Эти аспекты также формализованы и описаны.
В рамках Надежности реализована интеграция ИТ с информационной безопасностью. Область информационной безопасности разворачивается в собственную структуру областей управления, но при этом остается интегрированной с общей системой управления информационными технологиями.
Простой пример – построение системы управления событиями информационной безопасности. Мы подключаем объекты, собираем данные, настраиваем корреляцию. Но если появляется новый сервер, который был установлен без учета требований информационной безопасности и без прохождения согласований, он может не попасть под контроль. О таком объекте нужно знать, учитывать его как актив и включать в контур мониторинга и корреляции событий. Эти сценарии учитываются в описаниях.
Управление активами также описывается по принципу фрактальности и раскладывается на собственные составляющие, но этот блок уже был рассмотрен выше.
Образовательные программы и внедрение РИТМ в вузы
Дорожная карта РИТМ уже сформирована и представлена в открытом виде. Области управления должны трансформироваться в учебно-методические планы и программы подготовки специалистов.
С нами уже взаимодействуют Высшая школа бизнеса, Государственный университет управления, МИСИС и Финансовый университет. Коллеги на высоком уровне разрабатывают образовательные программы с привлечением соавторов РИТМ в качестве преподавателей. Я сам преподаю в МИСИС, в Высшей школе бизнеса и веду MBA-программу в Высшей школе экономики, используя эти материалы. Полученный в образовательном процессе опыт возвращается обратно в РИТМ и используется для его развития.
Все материалы распространяются по открытой лицензии. Методология должна оставаться общим достоянием.
Можно сказать, что мы переизобретаем велосипед, но перед этим был проведен сравнительный анализ существующих методологий. Я лично изучал COBIT, ITIL и ITAM в части управления активами, сопоставляя процессы, заложенные в РИТМ, с тем, что отражено в других подходах.
Мы анализировали, какие элементы присутствуют, какие отсутствуют в ГОСТах, приложениях и других методологиях.
Этот анализ проводится постоянно, включая новые методологии, которые продолжают появляться. Мы сравниваем их и стремимся идти в ногу со временем.
Организация работы над РИТМ и проверка гипотез
Более 150 авторов и 50 компаний участвуют в разработке методологии. Я являюсь одним из четырех архитекторов, которые разработали РИТМ, сформировали его структуру и сотовую модель, разработали соглашение о моделировании опираясь, в том числе, на художественные образы из русских, древнегреческих и древнескандинавских мифов.
Мы разработали способ организации работы над РИТМ. Работа выстроена по областям управления. У каждой области есть владелец, аналог product owner, который формирует команды и организует рабочие процессы. Существует верхний совет как ядро всей методологии и редакционная коллегия, которая проверяет материалы авторов на адекватность и целостность. Все материалы обсуждаются и дорабатываются в коллективном формате.
В РИТМ заложен путь проверки гипотез. Мы не просто описываем, как должно выглядеть управление продуктами и услугами, а проверяем эти гипотезы на практике. Мы работаем с компаниями, проводим глубинные интервью, анализы и обследования. Результаты этих исследований публикуются. В процессе возникает большое количество аналитических материалов, которые также становятся частью открытого контура.
Через исследования, опросы и встречи мы постоянно синхронизируем участников. Проводятся митапы. Например, мы собрали в Подмосковье около 80 человек, которые в течение трех дней работали совместно и синхронизировали подходы. Это важно, потому что разработка должна быть связана с продуктами и услугами, управление активами – с финансами, управление инцидентами – с информационной безопасностью. Все области управления должны работать согласованно.
Побочным эффектом этой работы стало понимание того, как организовывать взаимодействие больших групп людей. Этот опыт я применял, например, на форуме «Цифровая эволюция», где необходимо было синхронно работать с сотнями участников в течение нескольких дней.
Мы постоянно обкатываем групповую динамику, проверяем гипотезы на практике и выходим на гембу, рассказывая о том, что и как было сделано. Проводятся тематические мероприятия. В частности, в Яндексе был организован День финансов. В течение дня финансовые специалисты работали в формате воркшопов и совместно разрабатывали процессы.
РИТМ поддержан Минцифры России. Мы подписали меморандум с Максутом Шадаевым и наши наработки ложатся в программу стандартизации ИТ госорганов, мы участвуем в программах повышения производительности отраслей.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAMLEAD&CIO EVENT.
