Концепция ЕИП в управлении ИТ-службой

Уже стали общим местом рассуждения о постоянно растущем значении ИТ-услуг в экономике предприятия и, соответственно, о возрастающей ценности автоматизации деятельности в области предоставления этих услуг. Тем не менее, если посмотреть на проблему глазами нормального ИТ-менеджера, с хорошими инструментами здесь непросто. Функции ИТ-службы, в автоматизации которых наш менеджер может быть заинтересован, многообразны. Это, в традиционных терминах, и бизнес-моделирование, и управление проектами (в основном, проектами разработки и/или внедрения приложений), и управление требованиями пользователей, и бюджетирование, и кое-то еще. Возникает здоровое желание снять с полки некий программный продукт, охватывающий все эти функции в единой информационной среде, поскольку интуитивно понятно, что функции тесно взаимосвязаны и имеют много общих информационных объектов. Но вот тут-то и загвоздка. Наиболее продвинутые знатоки информированы о линейке IBM Rational. Это действительно концептуально (и во многом программно) целостный многофункциональный инструментарий, охватывающий практически все перечисленные выше разделы, хотя и с явным уклоном в управление разработкой новых продуктов, что для большинства ИТ-служб не столь актуально. Но с полки его так просто не снимешь — тяжеловат будет. Стоит дорого, внедряется непросто. Конечно, для 98% Top500, где он, по данным IBM, используется, это, видимо, не проблема. Но для тех предприятий, где стоимость овладения им запросто может превысить весь годовой ИТ-бюджет, IBM Rational решением не является. И что тогда?

Существуют, конечно, развитые инструменты по отдельным функциональным разделам. Для бизнес-моделирования — ARIS, BPwin, та же Rational Rose. Для управления проектами — Open Plan, Primavera, MS Project. Для управления требованиями — скажем, HP Open View. Но, во-первых, инструменты тоже, по большей части, тяжеловатые, во-вторых, разрозненные, информационно между собой не связанные, целостный процесс сами по себе не организующие. И в третьих — что особенно относится к инструментам бизнес-моделирования — мало практичные. Хотя тот же ARIS позиционируется и как инструмент визуализации, и как исходный материал для автоматизации, мне трудно себе представить практикующего менеджера, который в здравом уме и твердой памяти будет его для этой цели комплексно (сверх одной-двух картинок) использовать. Да и трудоемкость описания объекта здесь такая, что оное описание для работающего бизнеса заведомо утрачивает актуальность задолго до того, как будет составлено.

Так что же делать? А получается, что Бог на душу положит. Брать какие-то куски перечисленных инструментов, на скорую руку сшить их суровыми нитками незаменимого Excel, и, по мере сил, жить.

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

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

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

Место ИТ-службы в пространстве предприятия (организации)

Начнем, как положено, с нескольких простых общих соображений и определений.

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

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

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

Итак, мы выяснили, какие основные внешние объекты должны быть учтены в ЕИП ИТ-службы. Пойдем дальше, т.е. вглубь.

Функции ИТ-службы (состав ИТ-услуг)

ИТ-служба занимается оказанием услуг предприятию, в основном, трех сортов:

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

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

Объекты ЕИП ИТ услуг и функциональные модули системы управления ими

Попробуем посмотреть на проблему «по рабоче-крестьянски», глазами практического ИТ-менеджера (хотя он, разумеется профессионал, и здоровая профессиональная терминология ему не чужда).

Ветка разработки и внедрения

Бизнес-моделирование

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

Откуда берутся РМ? Рискнем предположить, что информационным объектом, поставляющим их, является структура управления предприятием, следовательно, в нашем ЕИП надо предусмотреть для нее место. Привязка персоны к РМ — суть штатное расписание. При посменной работе к одному РМ может быть приписано несколько работников.

Откуда берутся требования заказчика к функциям, отнесенным к каждому РМ? Выстроим следующую простую логическую цепочку. Существует функциональная структура предприятия, под которой мы понимаем дерево декомпозиции функций управления — от общего руководства бизнесом до частных операций типа отпуска материалов со склада или табельного учета. Нас в данном случае интересует эта структура «как должно быть» (считаем, что переход к ней от «как есть» «на бумаге» предваряет ИТ-услуги и непосредственно к ним не относится). Если мы построим такую структуру и привяжем функции к РМ, мы имеем уже что-то. Что-то, но еще недостаточное для дальнейшего осмысленного управления. Что же дальше?

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

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

Управление конфигурациями

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

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

Права доступа могут быть реализованы или индивидуально для каждого РМ или через шаблоны ролей в целях экономии затрат на проектирование. Отсюда появляется объект «роли».

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

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

Здесь мы пока остановим путь по ветке разработки и внедрения и обратим внимание на другие, благо, для их формирования нами уже создан определенный материал.

Ветка строительства инфраструктуры

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

Ветка эксплуатации

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

Управление требованиями

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

Целесообразно выделить два вида требований: требования заказчика и требования пользователя. Сразу оговоримся, что структура их отражения в ЕИП практически одинакова для обоих видов; различия проявляются на качественном уровне и на уровне процедур управления.

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

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

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

Управление работами

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

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

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

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

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

Общая структура

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

Этим тезисом мы можем с чистой совестью увенчать данный раздел изложения: функциональные модули системы управления ИТ-услугами определены, состав объектов ЕИП сформирован. Общий вид структуры полученного ЕИП может быть представлен на нижеследующей диаграмме. Указаны основные функциональные модули и объекты, обеспечивающие взаимосвязь модулей и поддержание информационных характеристик.

И под конец не удержимся от попытки внести вклад в сокровищницу консалтинговой терминологии: почему бы по аналогии с ERP не назвать изложенную концепцию IRP (Informational Resources Planning)? Забьем копирайт на эту идею и двинемся дальше.

Реализация концепции

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