Есть темы, которые не отнесешь к разряду обсуждаемых. Как правило, попытки журналистов получить комментарии к статье на такую тему наталкивают на искреннее недоумение и самих CIO, и поставщиков ИТ-решений. «…Да, есть проблема, но уж больно мелкая, до масштабного обсуждения ей еще расти и расти. У нас задачи глобальные, планов громадье, а вы на такие мелочи внимание обращаете. Стоит ли тратить на них время?...» Но при ближайшем рассмотрении оказывается, что проблема гораздо масштабнее и глубже, чем представлялось на первый взгляд. К таковым относится и проблема терминологии в области ИТ.
Рынок ИТ бурно развивается, приоритеты компаний лежат в области развития бизнеса, освоения рыночных ниш, увеличения доли прибыли. На этом фоне проблема упорядочивания терминологии выглядит мелкой и второстепенной: главное, чтобы у заказчика и исполнителя было правильное понимание решаемых задач, а как это назвать — вопрос десятый. Однако эта второстепенная проблема, как заноза, постоянно напоминает о себе. Специалисты, чья деятельность так или иначе связана со сферой информационных технологий, реализуя проекты, общаясь между собой в рамках различных мероприятий, читая профессиональные издания, воспринимают и передают информацию, используя термины, которые сегодня имеют неоднозначное толкование. А проблемы, возникающие из-за недопонимания и многозначного толкования терминов специалистами заказчика и исполнителя, никак не назовешь второстепенными.
«Если оценить потери компаний, связанные с тем, что сотрудники не договорились о терминах, то окажется, что они не так уж малы, — считает Александр Полыковский, директор отделения контроля качества департамента корпоративных систем управления IBS. — Сколько лишних совещаний и встреч приходится проводить, чтобы прийти к единому пониманию терминов и стоящих за ними понятий! Эти потери пока не принято учитывать. Ну, подумаешь — провели вместо одного совещания три или пять. Или консультанты из-за недопонимания настроили в системе бизнес-процесс неправильно — но ведь исправили же, хоть и потратили на это несколько лишних дней. Однако дополнительные совещания, перенастройка системы, изменение в проектных документах — это потерянное время и деньги».
Потери возникают не только в ходе проекта. Львиная доля контрактов не заключается вовсе не из-за некомпетентности исполнителя, а из-за того, что исполнитель, разговаривающий в других терминах, кажется заказчику некомпетентным. На этапе установления взаимоотношений с заказчиком ключевые персоны заказчика, функциональные лидеры, общаются с потенциальным исполнителем, проецируя собственную деятельность на привычные бизнес-термины. И если исполнитель ошибается в терминологии заказчика — для него это сигнал о некомпетентности исполнителя. Хотя во многих подобных случаях оказывается, что специалисты заказчика и исполнителя говорят об одном и том же, но употребляют разные термины.
Проблема терминологического хаоса актуальна и при общении внутри самих ИТ-компаний, причем она обостряется с их ростом. Пока компания невелика, отличия в толковании тех или иных терминов не являются очевидной помехой ее развитию. При небольшом штате сотрудники могут в личной беседе обсудить все неясные моменты и договориться. Но по мере роста и усложнения деятельности возникнет острая потребность в формализации и унификации бизнес-процессов и как следствие — связанной с ними терминологии. «Те проблемы недопонимания, на которые раньше можно было закрывать глаза, сейчас могут стать серьезным тормозом развития компании, — отмечает Александр Полыковский. — Если не будут предприняты шаги к ликвидации „многоязычности“ сотрудников, они просто перестанут понимать друг друга. Бизнес в сфере ИТ становится все более высокотехнологичным. Он все реже напоминает искусство и все чаще — ремесло в лучшем смысле этого слова. Сейчас заказчики довольно четко осознают свои потребности, ставят перед исполнителем конкретные цели и требуют их достижения. Заказчики хотят видеть компанию консультанта как промышленную, технологичную организацию с формализованными методиками, в том числе в области терминологии. Работа с терминологией в этом случае превращается в конкурентное преимущество ИТ-компании».
«Тысячи тонн словесной руды»
Любое недопонимание и для заказчика, и для исполнителя оборачивается реальными потерями времени и денег. Чтобы говорить на «одном языке», российским специалистам необходим русскоязычный терминологический эталон, причем не только в области ИТ — ведь проекты затрагивают огромный пласт отраслевой терминологии заказчиков. Но сегодня специалистам не на что опереться, кроме собственной интуиции.
От СССР российская сфера ИТ унаследовала ГОСТы — государственные и отраслевые стандарты. «В советское время техническая терминология формировалась в едином русле, хотя иногда колебалась вместе с генеральной линией партии, — рассказывает Алексей Заславский, консультант отделения „Ай-Теко Бизнес Консалтинг“. — Формирование и систематизация научно-технической терминологии осуществлялись при постоянной государственной поддержке. Так, комитет научно-технической терминологии АН СССР занимался подготовкой методологических материалов по терминологической работе и словарей, в частности по вычислительной технике, ряд терминологических проектов в области ИТ реализовывался под эгидой Госстандарта СССР. Однако сегодня многие термины в ГОСТах безнадежно устарели, а систематической государственной поддержки по развитию системы терминологических стандартов практически нет».
За неимением общепринятой системы стандартов специалисты вынуждены обращаться к разрозненным источникам, собирая собственный глоссарий, как паззл, - из отдельных фрагментов.
Часть терминов заимствуется из российских ГОСТов, получивших новые редакции сравнительно недавно: например, многие определения могут быть взяты из государственного стандарта по управлению качеством. Пробелы отечественных стандартов восполняются документами международных и национальных организаций Запада – в частности, Международной организации по стандартизации (ISO), например, ГОСТ Р ИСО/МЭК 9000:2001 «Системы менеджмента качества. Основные положения и словарь».
Кроме того, терминологическим источником зачастую служат развитые глоссарии вендоров, особенно флагманов рынка - SAP, Oracle, Microsoft. «Существенный минус заключается в том, что в терминологической документации вендоров существует сильный акцент на особенностях конкретных систем, поэтому такие термины требуют корректировки», - отмечает Александр Полыковский. По мнению Алексея Заславского, «определенную роль в формировании терминологии играют различные профессиональные сообщества, в рамках таких организаций часто разрабатываются и публикуются глоссарии профессиональных терминов. Конечно, они не носят характер стандарта «де-юре» и становятся стандартом «де-факто» среди ИТ-профессионалов». Трудности использования таких источников в немалой степени связаны со сложностями адекватного перевода терминов. «Основная проблема - это перевод и согласование русского варианта англоязычной терминологии, - отмечает Алексей Заславский. - Ведь каждый из нас воспринимает определенный термин в определенном контексте. Зачастую за одним термином мы видим несколько значений, а при переводе надо отдать предпочтение одному. Кроме того, итоговый текст должен корректно звучать с точки зрения русского языка». Важно отметить, что терминология базируется на законодательстве. Именно поэтому прямой перевод западных стандартов бывает невозможен.
Неиссякаемым источником служит Интернет – начиная от специализированных терминологических ресурсов, наподобие glossary.ru, сайтов, содержащих общие и отраслевые словари, и заканчивая разрозненными информационными ресурсами, откуда, перебрав «тысячи тонн словесной руды», можно извлечь «самородки» удачных определений. И, разумеется, одним из основных источников пополнения терминологического багажа остаются печатные словари.
Понять друг друга с полуслова
В результате использования различных источников в разных комбинациях компании в итоге де-факто формируют собственные уникальные терминологические поля. В общении специалистов одной организации с коллегами из других компаний или заказчиками довольно сложно найти точки пересечения этих полей. Тем не менее, находить общий язык, особенно в ходе проекта внедрения масштабной информационной системы, жизненно необходимо – неоднозначное толкование терминов ведет к недопониманию в команде проекта и наглядной реализации сценария «лебедь, рак и щука», со всеми вытекающими негативными последствиями.
Небольшие компании–поставщики решений, как правило, решают проблему в каждом проекте «на живую нитку», договариваясь с заказчиком о терминах в ходе проекта. Для крупных компаний, реализующих масштабные проекты, такой путь неприемлем. «Мы стараемся на ранней фазе проекта договориться о терминах, - рассказывает Александр Полыковский. – Дело в том, что любой крупный ИТ-проект – это совместный проект заказчика и исполнителя, и в проектную группу на равных входят сотрудники компании-заказчика и сотрудники ИТ-компании. И недопустимо, если выяснится, что заказчик и исполнитель понимали под некоторыми терминами совсем разные вещи. Это может поставить под угрозу успех проекта».
Многие крупные компании по собственной инициативе разработали свои системы формирования единого с заказчиком терминологического поля. В русле этой деятельности интересен опыт компании IBS, создавшей собственный глоссарий.
Базовая версия
В рамках каждого проекта есть фаза подготовки проекта, на которой формируются регламентирующие документы проекта (устав и др.). На этой же фазе специалисты IBS формируют глоссарий проекта — единый, согласованный заказчиком и исполнителем перечень терминов, которыми будут оперировать специалисты в ходе проекта. В качестве базового заказчику предоставляется глоссарий, сформированный в рамках департамента корпоративных систем управления IBS. Словарь состоит из нескольких разделов, которые охватывают не только термины сферы ИТ, но и терминологию из разных областей бизнеса. В глоссарии есть отдельные блоки: «ИТ», «Финансы», «Логистика», «HR» и т. п. Начиная проект, исполнитель предлагает заказчику свой глоссарий в качестве базового, который затем дополняется и уточняется в соответствии с представлениями заказчика, включая терминологию, привычную и понятную ему. В итоге создается глоссарий проектной группы, который служит гарантией, что в дальнейшем у участников проектной группы будет одинаковое понимание терминов.
У IBS уже накоплен реальный опыт не только создания глоссария, но и доработки и использования его совместно с заказчиком. «Мы долго обсуждали вопрос, стоит ли включать глоссарий в перечень документов, подлежащих обязательному утверждению со стороны заказчика, — рассказывает Александр Полыковский. — И в итоге пришли к выводу, что это не та тема, которую есть смысл выносить на самый высокий уровень управления проектом. Часто руководители чересчур ответственно относятся к обсуждению каждого определения, в результате чего согласовать глоссарий, состоящий из десятков и сотен терминов, в течение первой фазы оказывается невозможно. С другой стороны, собственного глоссария и, соответственно, культуры работы с ним на предприятии, как правило, не существует.
Как показывает наша практика, достаточно, если на этапе подготовки проекта глоссарий будет принят в качестве рекомендательного методологического документа. Он согласуется и используется внутри проектной группы с учетом уточнений, которые актуальны именно для этого предприятия».
Создание базовой версии глоссария на уровне департамента корпоративных систем управления IBS происходило непросто, хотя, казалось бы, здесь обсуждение шло между людьми, много лет работающими в одной команде и в одной области. Поскольку термины и их определения пришлось собирать из разрозненных источников, существовало несколько вариантов толкования одних и тех же терминов. Бурные дискуссии о том, какое определение достойно включения в глоссарий, грозили затянуться надолго – ведь в них участвовало более 500 сотрудников департамента корпоративных систем управления IBS. В конце концов, было принято решение передать формирование терминологических блоков по каждому направлению деятельности – управлению финансами, логистикой, персоналом, документооборотом и так далее. Задачей, ответственностью и правом руководителя функционального подразделения было предложить для глоссария ту терминологию, которую он и его коллеги считали необходимой: ведь они отвечают за данный участок бизнеса, реализуют проекты, общаются с клиентами. Базовая версия появилась на свет около двух лет назад и уже успела пережить вторую редакцию.
Помимо глоссария, который формируется на первой фазе проекта, IBS ввела еще одну интересную практику. В начало каждого проектного документа, требующего согласования с заказчиком, помещается перечень упомянутых терминов с их толкованием. Когда все нужные определения фигурируют в самом начале документа, это позволяет избежать непонимания при рассмотрении документа. Подобная практика существует уже довольно давно, показала свою жизнеспособность и очень хорошо воспринимается заказчиком. Когда термины истолкованы, специалисты четко понимают, о чем речь, в противном случае такое понимание не гарантировано.
Александр Полыковский высказал пожелание заказчикам: «Инициатива нахождения общего языка и уточнения терминов должна исходить с двух сторон, и лучше договориться вначале, чем потом ликвидировать последствия. Многие заказчики, достигшие высокого уровня зрелости, уже осознают, что, не договорившись о правилах и терминах, они ставят под угрозу успех своего проекта. В конечном итоге исполнитель рискует лишь не получить деньги за проект. Риск заказчика гораздо больше — не создать систему».
От частного к общему
Опыт IBS не уникален, аналогичные глоссарии уже созданы и успешно используются в проектах многих крупных российских компаний сферы ИТ. Наступило время объединить усилия флагманов рынка по выработке единой терминологии. «Каждая компания в процессе своей деятельности постоянно взаимодействует со множеством заказчиков и своих коллег по рынку, — говорит Александр Полыковский. — Мы не хотим тратить время на проблемы, которые возникают из-за того, что подчас говорим на разных языках. Лучше договориться. Если наши партнеры будут общаться на том же языке, что и мы, они будут разговаривать на нем и со своими заказчиками. Таким образом, на рынке постепенно сложится единое терминологическое поле». Первые шаги в этом направлении уже сделаны.
В деятельности по созданию единого терминологического поля российские ИТ-специалисты опираются на опыт зарубежных коллег. На Западе разработкой терминологических стандартов занимаются, как правило, некоммерческие партнерства. Крупные компании, которые являются ключевыми в отрасли, объединяются, создают некоммерческие партнерства и разрабатывают стандарты, в том числе терминологические. «На мой взгляд, есть только один вариант выработки единой терминологии, — уверен Александр Полыковский. — Несколько ключевых ИТ-компаний на уровне руководителей должны собраться за одним столом и принять программу выработки единой терминологической базы. Если инициативу в этой сфере проявит государство, то, конечно, к работе необходимо будет привлечь ключевые компании ИТ-рынка, иначе вводимая терминология рискует остаться только на бумаге — она будет сильно отличаться от используемой в повседневной практике». Именно такое решение проблемы — «всем миром» — считает одним из наиболее рациональных и компания «Ай-Теко», координирующая российский проект в области формирования терминологии ИТ. «Деятельность по формированию единой терминологической базы разворачивается в одной из наиболее востребованных и популярных сегодня областей ИТ — управлении ИТ-услугами (IT Service Management — ITSM), — рассказывает Алексей Заславский. — Несколько лет назад принципы подхода ITSM, к тому моменту уже широко известные на Западе, начали активно набирать популярность и в нашей стране. Появились переводные и оригинальные статьи, были проведены первые учебные курсы по данной тематике на основе аналогичных западных курсов. Авторами этих статей и тренерами учебных курсов выступали представители разных компаний, что, естественно, привело к определенным различиям используемой терминологии».
Знаковым событием для российского рынка управления ИТ-услугами должен стать выход национального стандарта в области управления услугами в сфере информационных технологий ГОСТ Р ИСО/МЭК 20000, подготовленного на базе аутентичного перевода международного стандарта ISO/IEC 20000:2005. Проект данного стандарта подготовлен компанией «Ай-Теко». «При подготовке стандарта консультанты „Ай-Теко“ столкнулись с задачей обеспечения непротиворечивости терминологии, используемой в стандарте, с другими уже принятыми российскими стандартами, с одной стороны, и „де-факто“ сложившимся терминологическим базисом в среде ИТ — с другой. Не без трудностей, но был найден необходимый баланс», — рассказал Алексей Заславский. Другое значительное событие — выход третьей версии Библиотеки ITIL (IT Infrastructure Library). Вопрос о переводе третьей версии ITIL, скорее всего, будет определен в рамках российского отделения международного форума itSMF — некоммерческого партнерства, объединяющего специалистов в области управления ИТ-услугами.
«Сейчас акценты смещены в сторону роста бизнеса, но через некоторое время, когда развитие компаний замедлится, на первый план выйдут факторы повышения эффективности, которые сейчас скрыты, в том числе и терминология. Но, разумеется, между осознанием ситуации и появлением стандартов пройдет довольно много времени. Это длительный и сложный процесс», — отмечает Александр Полыковский.
«Однако очень хочется, чтобы терминологические споры в кругу ИТ-профессионалов не становились самоцелью. Вопрос о том, как в том или ином контексте более корректно перевести термин continuity — „непрерывность“ или „бесперебойность“, — конечно, важный, но для ИТ-профессионалов главное — обеспечить эффективное использование современных информационных технологий в интересах их потребителя», — резюмирует Алексей Заславский.
