Все действия, которые происходят в компании, можно разделить на процессы и проекты.
Проект — это работа, которая выполняется один раз; полученный результат является однократным и не требует повторения.
Процесс — это последовательность действий, которая повторяется регулярно. Когда в компании возникает вопрос построения процессов, чаще всего имеется в виду не то, что процессы надо построить, а описание их текущего состояния и разработка плана дальнейших действий.
Процессы выполняются в каждой компании. Согласно официальному определению (ГОСТ), процессом называется регламентированная последовательность действий, преобразующая некоторые входы в выходы. Такая деятельность есть в любой компании, и в эксплуатации ИТ ее можно обнаружить всегда. Ежедневно пользователи сообщают о каких-либо инцидентах, еженедельно в инфраструктуру вносятся изменения, ежегодно проводится аудит состояния инфраструктуры.
Прежде чем рассказать об основных мифах, сопровождающих проекты по построению и описанию процессов, вспомним два понятия для процессов, которые часто путают, — это зрелость и качество.
Качество процесса — это отношение получаемого результата к ожиданиям. Зрелостью же называется контролируемость процесса, его прозрачность и готовность к изменениям и оптимизации.
Процесс может иметь низкий уровень зрелости и при этом быть качественным. Например, в маленькой компании, где вся ИТ-инфраструктура состоит из четырех-пяти персоналок и одного сервера, процесс управления инцидентами может иметь от силы первый уровень зрелости (из общепринятых шести — с нулевого по пятый): описания нет, метрик нет, проблемы устраняет приходящий раз в неделю знакомый студент-компьютерщик. Не исключено, что для небольшой фирмы этого достаточно, и в итоге процесс получается незрелый, но качественный: директора он вполне удовлетворяет.
Возможна и обратная ситуация. Процесс управления инцидентами с очень высоким уровнем зрелости в крупной компании может быть отлично описан, полностью прозрачен и контролируем, может регулярно собирать множество метрик, но при этом не удовлетворять требованиям бизнеса. Зрелость — высокая, получаемый результат — ниже ожидаемого.
Что дает зрелость процессов компании? Управляемость. Процессу не хватает качества, но это — управляемо. Можно поспорить, но мне кажется, что это лучше, чем достаточное качество при полной неуправляемости действий: сколько такое качество будет держаться, никто сказать не может.
Что мы можем сделать с имеющимися процессами? В первую очередь — взять их под контроль.
Сначала нужно поверхностно оценить зрелость процессов. Для этого существует неплохой инструмент Self Assessment Tool (текущая версия — 2.0, бесплатная, можно скачать с сайта Microsoft). С помощью данного инструмента можно оценить зрелость процессов в компании и более четко определить для себя направление движения в будущем.
Второй шаг — исследовать и документировать текущее состояние процессов. Задача достаточно трудная, поскольку для ее выполнения требуется разработать в первую очередь стандарт документирования процессов, учитывающий специфику компании, географическую распределенность, организационную структуру и тому подобные тонкости.
Рекомендуется выбрать один процесс и провести его описание. Информация для описания процесса чаще всего составляется из двух вещей: текущая документация (которая может быть разрозненной) и общение с сотрудниками — исполнителями процесса. Не надо удивляться, если результаты бесед с сотрудниками будут значительно отличаться от инструкций: очень часто бывает, что инструкции, не поддерживаемые в актуальном состоянии, просто устаревают.
После описания и публикации первого процесса сбора информации можно приступать к описанию остальных процессов. Практика показывает, что на описание первого процесса уходит столько же времени, сколько на описание последующих четырех-пяти процессов.
Далее необходимо ввести всю полученную процессную документацию в документооборот компании и «накрыть» документы процессом управления изменениями. Если в компании нет более или менее отлаженного процесса управления корпоративной документацией и внесения в нее изменений, вся работа, скорее всего, будет проделана зря, и документы устареют уже через несколько месяцев.
Следует отметить, что описание процессов все равно остается просто бумагой. Для того чтобы процессы работали, необходимо их исполнение.
Вот самые распространенные мифы о процессах.
Миф №1: «Есть ITIL, есть MOF, мы их внедрим, и будет нам счастье»
Реальность: просто внедрение процессов «по книжкам» зачастую бессмысленно. Не стоит отдавать дань моде. ITIL и MOF — всего лишь накопленный опыт, показывающий: «А вот так сделано у многих; не изобретайте велосипед, не исключено, что у вас примерно то же самое». В то же время я не раз сталкивался с ситуацией, когда менеджер требовал изменить действия в достаточно отлаженном процессе управления инцидентами.
Миф № 2: «Придут умные консультанты и все сделают. И будет нам счастье»
Реальность: внешний консультант, который приходит в компанию, имеет опыт работы в других компаниях. Но не в вашей! Как построить процессы так, как надо вам, он может только подсказать. Он может указать на заведомо тупиковые пути, может рассказать, «как это у других», может систематизировать ваши знания и составить общую картину, в которую можно вписать то, что уже есть, и то, что планируется достроить; поможет с автоматизацией. Выстроить реальный процесс в реальных подразделениях и запустить его — это управленческая работа, которая под силу руководителям подразделений, но не внешним консультантам.
Миф № 3: «Ну их, эти MOF`ы и ITIL`ы. Работали без них, и дальше обойдемся»
Реальность: MOF и ITIL, помимо накопления передового опыта, выполняют другую важную функцию — они дают общую картину того, из чего вообще состоит вся эксплуатация. Как уже говорилось выше, процессы в компании все равно есть, от этого никуда не деться. MOF и ITIL помогают не только описать процессы, но и понять их место в общей картине процессов компании, могут оптимизировать то, что есть сейчас, подать идеи для оптимизации операционных расходов и построения смежных процессов.
К тому же описание и построение процессов, хотя бы в терминологии соблюдающих общий передовой опыт, значительно облегчают впоследствии как аудит, так и работу внешних консультантов с данным процессом спустя несколько лет. Иногда попадаются документы, в которых неплохо описан процесс, скажем, управления изменениями; в нем нет ни единого более или менее знакомого термина, и приходится ворошить глоссарий (если он есть) и практически учить новый язык.
Миф № 4: «Процессы — ерунда. Очередные бумажки, которые лягут на полку»
Реальность: к сожалению, иногда подтверждает миф. Но есть два пути, чтобы застраховаться от этого. Без наличия или предпосылки к созданию подобных вещей начинать проекты по созданию или описанию процессов просто опасно — ожидаемого результата не будет.
Первое — это организация исполнительного документооборота компании. Когда каждый разработанный, согласованный и подписанный к исполнению документ доводится до исполнителя и вводится в перечень должностных инструкций, а его исполнение измеряется и контролируется — тогда процессы начинают работать.
Второе — по возможности комплексная автоматизация выполнения. Все этапы процессов, которые можно автоматизировать, следует автоматизировать. Везде, где можно предупреждать пользователя о том, что ему надо сделать, — надо предупреждать.
По статистике, только 20% сбоев происходят по вине программного обеспечения или «железа». 80% — это именно «человеческий фактор» и ошибки в выполнении процессов.
В настоящее время на рынке предлагается множество средств автоматизации процессов, от комплексной автоматизации крупных поставщиков до небольших продуктов, покрывающих отдельные участки процессной деятельности.
Одно из средств автоматизации процессов — продукт System Center Service Manager, до последнего времени более известный как Microsoft Service Desk. Сейчас продукт находится на стадии первой общедоступной бета-версии и доступен для загрузки на портале Microsoft Connect.
В данном продукте есть некоторые логические ограничения, и текущую версию использовать достаточно тяжело, но уже можно ознакомиться с той стратегией, которую вырабатывает компания Microsoft в области автоматизации процессов эксплуатации ИТ.
Руслан Акмеев (ruslan@akmeev.ru) — консультант по MOF/ITIL в Microsoft Consulting Services