Все чаще сообщается о проектах внедрения в той или иной российской компании различных систем управления ИТ. Однако при этом, под одними и теми же понятиями нередко подразумеваются совершенно разные вещи или, напротив, одно и то же обозначают разными терминами. Налицо — проблема отсутствия единой терминологии.
Причина расхождений в терминологии кроется, с одной стороны, в недостаточном опыте реализации подобных проектов у компаний, продвигающих технологии управления, а с другой, в отсутствии отечественных формализованных методик проектирования и внедрения таких систем. Это вынуждает использовать западные опыт и методологии, что влечет за собой проблемы как перевода и восприятия новых терминов, так и их адаптации к специфическим требованиям российских заказчиков.
Скажем, многие считают ITIL методологией. Каков на самом деле смысл этой аббревиатуры, мы рассмотрим чуть позже, а пока ограничимся утверждением: чтобы проект внедрения информационной системы имел шанс на успех, заинтересованные стороны должны говорить на одном языке, то есть использовать согласованную терминологию. Это означает, что все термины должны однозначно трактоваться всеми участниками проекта в течение всего срока внедрения, а по окончании проекта необходимо обеспечить «передачу» терминологии пользователям информационной системы.
Проблему определения терминов усложняет относительная новизна для отечественных ИТ-профессионалов как самой идеи перехода ИТ-департамента от управления ИТ-ресурсами к управлению поддержкой предоставления услуг, так и специфика предметной области, охватывающей всевозможные системы управления ИТ.
Договоримся, что под системами управления ИТ мы будем понимать любые системы, обеспечивающие управление элементами ИТ-инфраструктуры или автоматизацию работы ИТ-подразделения. Эти системы призваны, с одной стороны, облегчить и упорядочить функционирование ИТ-подразделения, а с другой, повысить эффективность его деятельности. Системы данного класса постоянно усложняются, тесно интегрируются друг с другом, появляются новые консолидированные решения для организации стратегического планирования и управления ИТ. Так, системы автоматизации служб технической поддержки существуют уже много лет, но сегодня позволяют автоматизировать не только выполнение основных задач таких служб, но и управление изменениями в ИТ-инфраструктуре и согласованным уровнем ИТ-услуг.
Усложняется и терминология. В качестве примера можно вспомнить, как эволюционировали системы управления ИТ. Все начиналось с так называемых базовых средств автоматизации, типичными представителями которых можно считать системы мониторинга и управления сетевой инфраструктурой. При их внедрении мы имели дело с устоявшейся терминологией мира локальных и глобальных сетей. Сегодня появились системы, позволяющие управлять предоставлением ИТ-услуг. А поскольку теперь мы имеем дело с управлением на более высоком уровне — уровне автоматизации ИТ-процессов, нам приходится оперировать и совершенно иной терминологией, содержащей множество взаимосвязанных понятий.
Нередко определения терминов содержат ссылки друг на друга. Так, суть ИТ-услуги раскрывается с помощью понятия ИТ-ресурса, поскольку ИТ-услугу можно определить как обеспечение потребителю определенной функциональности при использовании ИТ-ресурсов. В свою очередь, под ИТ-ресурсом подразумевается совокупность программно-аппаратных средств, необходимых для предоставления пользователю определенной функциональности. (Чтобы облегчить восприятие последнего определения, мы намеренно «ушли» от ссылки на термин «элемент ИТ-инфраструктуры».)
Неотъемлемость терминологии от методологии
Появление библиотеки ITIL (Information Technology Infrastructure Library) — квинтэссенции мирового опыта в области организации работы ИТ — стало толчком к развитию методологий построения систем управления ИТ. Собственную методологию HP Information Technology Service Management (HP ITSM) предложила компания Hewlett-Packard, имеющая в своем арсенале программное обеспечение для построения различных систем автоматизации, мониторинга и управления. HP ITSM была создана на базе ITIL с учетом опыта Hewlett-Packard и возможностей данного программного обеспечения. Согласно заявлениям компании, HP ITSM представляет собой именно методологию, так как, по сути, является четким, последовательным и детализированным руководством к действию. И, конечно же, эта методология раскрывается с помощью развитой терминологии, которая, хоть и несущественно, отличается от терминологии ITIL.
Ярким примером таких несоответствий можно считать предложенное Hewlett-Packard жесткое различение заявок на обслуживание (Service Call) и инцидентов (Incident). Под инцидентами понимаются сбои, зафиксированные автоматизированными системами мониторинга и контроля ИТ-инфраструктуры, а под заявками на обслуживание — обращения конечных пользователей. Заявки могут быть разных типов, в том числе «запросами на устранение инцидента» или просто «инцидентами». При этом, с точки зрения компании, заявка на обслуживание «типа инцидент» и просто «инцидент» — совершенно разные понятия.
В ITIL же используется иная классификация, в которой понятие «заявка на обслуживание» напрямую не определено, зато есть понятие запрос на обслуживание (Service Request) как подмножество понятия «инцидент». Соответственно, сам «инцидент» в ITIL определяется иначе, чем в HP ITSM. Основная причина несоответствия, по-видимому, кроется в том, что Hewlett-Packard подходит к рассматриваемым вопросам с точки зрения поставщика ИТ-услуг.
Понятно, что рассмотренные несоответствия не принципиальны, но должны учитываться для обеспечения взаимопонимания заказчика и подрядчика. Иначе может возникнуть неприятная ситуация: на определенной стадии проекта вдруг выяснится, что одними и теми же терминами они обозначали принципиально разные вещи.
Корпорация Microsoft недавно предложила основанную на ITIL методологию MOF (Microsoft Operations Framework), отражающую ее собственный опыт и особенности выпускаемого ею программного обеспечения. Терминология MOF отличается от таковой в ITIL и HP ITSM, причем основные различия состоят в названиях терминов, а не в их сути. Восприятие концепции MOF во многом осложняется новизной для Microsoft этого рынка, на котором Hewlett-Packard и IBM работают уже давно. Сейчас Microsoft пытается исправить ситуацию, активно сотрудничая с организациями, которые участвуют в издании библиотеки ITIL.
Методологические отличия MOF от HP ITSM очень хорошо видны при сравнении так называемых процессных моделей — основе этих методологий (см., например, статью Владимира Бахметьева «MOF дополняет ITIL», «Открытые системы», 2004, №1). Даже беглый взгляд на обе модели позволяет заметить: несмотря на их общее сходство и заверения обеих компаний в том, что их методологии базируются на ITIL, они значительно различаются в деталях. Возможно, дело состоит в новизне предмета, и через некоторое время все «придет к единому знаменателю», но с учетом инертности крупных корпораций и их приверженности к введению собственных уникальных определений маловероятно, что процесс утряски терминов окажется скорым. При этом количество проектов, связанных с ITIL, лавинообразно растет, и времени на ожидание попросту нет.
Бессмысленно рассуждать о преимуществах этих методологий — каждая из них учитывает специфику программного обеспечения конкретного производителя. Однако HP ITSM и MOF — частично открытые методологии, активно продвигаемые на рынке. Используемые в них термины постоянно на слуху, что, с одной стороны, еще больше расширяет терминологическую базу, а с другой, вносит дополнительную путаницу. В таких условиях незавидно положение команды специалистов, внедряющей, например, систему автоматизации службы технической поддержки на основе технологий Hewlett-Packard на предприятии, где базовые средства автоматизации реализованы на основе технологий Microsoft.
Разбухание терминологической базы в области построения консолидированных систем управления ИТ весьма осложняет работу независимых консультантов и системных интеграторов. Положение усугубляется тем, что методологии разных производителей открыты лишь отчасти, так как содержат ноу-хау. Это исключает прямое использование таких методологий и вынуждает системных интеграторов инициировать разработку собственных методик (что само по себе неплохо) и собственной терминологии, которая может отличаться от принятой другими поставщиками аналогичных услуг и продуктов. В результате осложняется жизнь не только заказчиков, но и самих интеграторов.
Конечно, нельзя игнорировать методологии, предлагаемые крупными корпорациями, — в них заложен большой практический опыт. Более того, в методологиях производителей программного обеспечения учитываются особенности последнего. Однако есть и обратная сторона медали, заключающаяся в желании производителей программного обеспечения навязать свое мнение, в том числе относительно терминологии. Например, при построении систем управления на базе программного обеспечения Hewlett-Packard необходимо ориентироваться на терминологию HP ITSM, поскольку использование многих ее понятий уже «заложено» в соответствующих продуктах и их переопределение нежелательно. Возвращаясь к терминам «инцидент» и «заявка на обслуживание», следует отметить, что продукт HP Openview Service Desk, который ориентирован на автоматизацию процессов поддержки предоставления ИТ-услуг, вполне естественно оперирует понятиями в соответствии с методологией HP ITSM.
Адаптация западной терминологии
Недостаток опыта и отсутствие собственных формализованных методик проектирования и внедрения систем управления ИТ не оставляют российским системным интеграторам другой возможности, кроме как перенимать западный опыт. Однако вполне вероятно, что попытка скопировать чужую методологию — естественно, вместе с терминологией — при недостатке собственного опыта закончится неудачей: отечественный заказчик часто запускает нетипичные для его западного коллеги ИТ-процессы и, как следствие, пользуется иными подходами к управлению ИТ-инфраструктурой.
В качестве яркого примера можно рассмотреть автоматизацию управления изменениями в ИТ-инфраструктуре в рамках службы технической поддержки. Опыт показывает, что наиболее сложным является внедрение одной из основных процедур этого процесса — утверждения изменений. Дело в том, что внедрение такой процедуры, согласно западным методологиям, требует очень высокой степени формализации должностных инструкций и четкого разграничения ответственности сотрудников ИТ-служб в рамках процесса управления изменениями. А как раз этого на многих отечественных предприятиях пока нет.
Кроме того, имеется языковой барьер, следствием которого становится неоднозначность перевода терминов на русский язык (например, «service» можно перевести и как «услугу», и как «ресурс», и как «службу»). Последнее особенно важно, поскольку термины нельзя адекватно перевести в отрыве от методологии. Необходим собственный опыт, чтобы, применяя западную методологию, убедить заказчика перестроить те или иные ИТ-процессы или изменить структуру ИТ-подразделения. Рассуждения о том, что это позволит соответствовать прогрессивной западной методологии, не всегда впечатляют заказчика.
Использование ITIL «в чистом виде» также не решает всех проблем. Эта библиотека описывает лучшие решения и мировой опыт в области организации работы ИТ-департамента и управления ИТ, но не содержит руководства к действию. ITIL не является методологией, и часто применяемое в России словосочетание «методология ITIL» подтверждает именно наличие проблем с пониманием западной терминологии. ITIL разъясняет, как должен функционировать ИТ-департамент, какие ИТ-процессы нужно обеспечить и какие системы внедрить, но не дает рекомендаций, как внедрять такие системы, поэтому утверждения типа «мы будем внедрять все по ITIL» попросту некорректны. Естественно, эта библиотека должна приниматься во внимание при внедрении систем управления ИТ, а терминология ITIL — адаптироваться с наименьшими отклонениями от оригинала.
Выходом из ситуации, по-видимому, является адаптация западного опыта, западных методологий и терминологии с учетом российской действительности и, пусть небольшого, опыта отечественных системных интеграторов, работающих в области автоматизации управления ИТ. Очевидно, что терминология должна быть согласована всеми ведущими интеграторами и одобрена всеми производителями программного обеспечения. Другими словами, необходимо создать некоторое подмножество основных терминов в сфере управления ИТ, которые будут одинаково трактоваться каждым представителем российского ИТ-сообщества.
Важно отдавать себе отчет в том, что методология и терминология могут изменяться по мере накопления опыта: ИТ-индустрия динамично развивается, и догмат в ней принципиально невозможен. ITIL тоже не стоит на месте — периодически выходят новые книги или обновленные редакции старых.
Движение навстречу
В рамках каждого конкретного проекта в терминологии неизбежно должны учитываться специфические требования заказчика — при неизменности основополагающих терминов. Не учитывать эти специфические требования нельзя, поскольку можно спровоцировать конфликтные ситуации и отторжение навязываемой терминологии. Прав был Платон, утверждая в «Диалогах»: «Ни одно имя никому не врождено от природы, оно зависит от закона и обычая тех, кто привык что-либо так называть». Иными словами, полностью разрушить сложившуюся терминологию и навязать принципиально новую — трудноразрешимая задача, по крайней мере, при внедрении отдельной системы управления ИТ. В свою очередь, отторжение терминологии может привести к тому, что внедряемое решение не даст ожидаемого эффекта.
Андрей Кутуков (akutukov@topsbi.ru) — технический эксперт компании TopS Business Integrator (Москва).
Не только терминология ITIL
Перевод на русский язык — это перевод с одного иностранного языка на другой иностранный язык. — Профессор А.А. Лебедев
Русская терминология в области информационных технологий формируется на основе англоязычных публикаций. Английский язык, в отличие от русского, технологичен и прост, слова и термины в нем лепятся буквально из ничего — лишь бы было понятно. Подобное словотворчество в русском языке не всегда возможно: полученные термины режут слух и кажутся неправильными, хотя являются вполне корректным с точки зрения грамматики.
Книга «Введение в ИТ Сервис-менеджмент» (книга Форума itSMF, гл. редактор английской версии Ян Ван Бон (Jan van Bon), перевод на русский язык под ред. М.Ю. Потоцкого) — первое печатное издание на русском языке по методологии ITIL/ITSM. Книга переведена на достаточно высоком профессиональном уровне, но поражает пренебрежение в ней правилами русской орфографии. Следуя англоязычному оригиналу, переводчики повсеместно используют в именованиях терминов прописные буквы: Управление Изменениями, Запрос на Изменение, Управление Проблемами, Конфигурационная Единица и т.п. Но если в английском языке это вполне соответствует нормам, то в русском — нет.
Аналогичная ситуация наблюдается и в ряде других публикаций по ITIL/ITSM. Сторонники прописных букв в именованиях терминов называют следующие причины пренебрежения правилами.
- Специалисты настолько трепетно относятся к терминам ITIL/ITSM, что подсознательно воспринимают их как имена собственные.
- Специалисты используют строчные буквы в именованиях терминов при обсуждении дисциплины вообще. Если же речь идет о конкретной дисциплине в конкретной организации, часто применяются прописные буквы. (На самом деле, прописные буквы встречаются в обоих случаях.)
- Есть правила русского языка, но нет механизма принуждения (наказания за их неисполнение), следовательно, эти правила являются рекомендательными и их можно нарушать.
- Правила любого языка всегда отстают от реалий языкового общения, и сегодняшняя безграмотность через какое-то время может стать нормой.
Определенное беспокойство вызывает тезис о прерогативе мнения заказчика при выборе терминологии в процессе внедрения ИТ-систем. Конечно, заказчик может использовать «внутриведомственную» терминологию, но такая самоизоляция вряд ли пойдет ему на пользу. Действительно, во многих организациях применяется терминология в области ИТ, унаследованная от ранее внедренных систем и не имеющая ничего общего с общепринятой. И с этим нужно что-то делать. По крайней мере, на уровне основополагающих терминов.
И еще, на что хочется обратить внимание. Иногда корректно переведенный термин может не иметь в русском языке тех значений, которые есть в английском. Скажем, слово «business» в русскоязычных публикациях по ITIL/ITSM обычно переводится буквально — «бизнес». Но контексты значений английского слова и его русского эквивалента различны. По Ожегову бизнес — это «предпринимательская экономическая деятельность, приносящая доход, прибыль», английское же слово «business» имеет, как правило, значение «деятельность вообще». Поэтому при механическом переводе могут образовываться двусмысленные выражения, например, «бизнес правительства», «бизнес некоммерческой организации».
Одной из важнейших задач применения современных ИТ является преодоление разобщенности между руководителями и специалистами ИТ-департаментов, а также их заказчиками и пользователями. Важную роль здесь играет выработка единой терминологии («общего языка»), точно определенной и понятной всем. Вместе с тем наблюдается большое расхождение в русских переводах терминов, даже иногда в рамках одной публикации или одного публичного сообщения штатного «русскоязычного» специалиста зарубежной компании.
Терминология в области ИТ довольно динамично развивается, особенно в последние годы, но организованная деятельность по ее упорядочению в нашей стране уже давно всерьез не ведется. Приведем, например, комментарий председателя Орфографической комиссии РАН профессора В.В. Лопатина (он не потерял актуальности, хотя был дан в 2001 году): «Сектор орфографии и орфоэпии Института русского языка им. В.В. Виноградова РАН и Орфографическая комиссия РАН, к сожалению, не имеют возможности заняться проблемами научно-технической терминологии, хотя я охотно соглашаюсь, что эта сфера современной научно-общественной деятельности требует большого внимания и упорядочения. Если этот вопрос приобрел столь большую остроту, советую обратиться в Правительство с просьбой найти способ активизировать деятельность Комитета по научно-технической терминологии» (www.oracle.com/ru/oramag/ august2001/index.html?meth_termins.html).
Нельзя не признать правоту Лопатина: научно-технической терминологией, как и специальной терминологией в других областях, прежде всего, должны заниматься специалисты конкретной предметной области. Роль профессиональных филологов в такой работе может быть лишь вспомогательной, хотя их консультации, без сомнения, окажутся весьма полезными (как, например, в случае с прописными буквами в именованиях терминов).
Несмотря на отсутствие организованной на государственном уровне работы по упорядочению научно-технической терминологии в нашей стране, следует заметить, что в том или ином виде она ведется силами энтузиастов. Так, на Евразийском форуме по управлению сервисами терминологические вопросы обсуждаются в разделе «Терминология» (itsm.itpark.ru), а журнал Oracle Magazine/Russian Edition имеет дискуссионную терминологическую колонку «О чистоте русского языка и точности терминологии». Можно привести и другие примеры подвижнической деятельности.
«Озвучивание» терминологических проблем, их обсуждение со специалистами, обмен мнениями с лингвистами, все это, несомненно, — полезное дело. Можно принимать или не принимать какие-то рекомендации, но если нет желания слушать и делать конструктивные выводы, дальнейший разговор бесполезен.
— Александр Соколов (ap_sokolov@mail.ru), сотрудник компании РДТЕХ (Москва). Автор исходной локализации СУБД Oracle, создатель кодировки ISO-8859-5.
