Конфигурирование и адаптацию программного обеспечения по смыслу часто путают— оба термина нередко используют как синонимы, когда речь идет о модификации ПО для его соответствия специфическим требованиям заказчика. Программное обеспечение можно назвать конфигурируемым, если его можно настроить через стандартные интерфейсы без программирования дополнительных функций и/или без изменения исходного кода программы. Если требования к системе нельзя удовлетворить без программирования или изменения исходного кода, то программное обеспечение принято называть адаптируемым.
Важным аспектом, отличающим конфигурирование от адаптации, является существенная разница в требуемых ресурсах и уровне компетенции персонала для достижения нужного результата. Адаптация готового решения требует значительно больше ресурсов, причем не только в момент внесения изменений, но и в течение всего жизненного цикла решения.
Возможности системы автоматизации службы поддержки определяются рыночным спросом— если спрос на определенную возможность продукта достаточно высок, производители будут такую возможность разрабатывать для своих решений, и она очень быстро получит распространение на рынке как «стандартная» функция; а если требование не пользуется массовым спросом, то соответствующие функции разрабатываются таким образом, чтобы их можно было поддерживать с помощью дополнительных изменений и настроек, что потребует от пользователя дополнительных расходов. Если же требования к функциональности уникальны, то маловероятно, что пользователь сможет найти уже имеющееся решение, поэтому реализация будет существенно отличаться от возможностей готового (out-of-the-box) продукта. На модификацию в соответствии с требованиями уникальных спецификаций потребуется больше усилий квалифицированных специалистов и неизбежно затраты на реализацию будут выше.
Подходы к настройке и адаптации функциональности ITSM-платформы
Можно выделить шесть основных способов, с помощью которых путем конфигурации и адаптации готовое приложение можно превратить в требуемое решение.
Подбор готовых модулей и компонентов. Этот способ предусматривает выбор одного или нескольких компонентов из набора модульных решений, каждое из которых реализует определенную функциональность так, чтобы сформировать общее решение, «наилучшим образом» отвечающее требованиям клиента.
Настройка пользовательского интерфейса, прав доступа и бизнес-логики. Большинство корпоративных ITSM-решений включают в себя инструментальные средства конфигурации пользовательского интерфейса, права доступа и логики,— это позволяет достигнуть гибкости, необходимой для удовлетворения требований клиента без программирования скриптов, дополнительного кода и глубоких технических знаний. Такой подход предусматривает моделирование последовательности заданий и бизнес-логики, создание и изменение форм пользовательского интерфейса, поддержку прав доступа и «придание» продукту определенного внешнего вида.
Модификация структуры метаданных. В этом случае структура готовой базы данных меняется таким образом, чтобы она лучше соответствовала требованиям, предъявляемым к данным в конкретной организации: добавление новых таблиц, изменение типов данных, установка атрибутов данных.
Использование встроенной среды разработки. Такая среда занимает промежуточное положение между инструментами настройки и полномасштабной разработкой программного обеспечения. Некоторые решения предоставляют интегрированную среду разработки, в рамках которой пользователь с помощью внутреннего языка программирования может разрабатывать специальные клиентские инструменты.
Разработка с использованием программных интерфейсов. Некоторые из ITSM-решений предоставляют стандартизованные программные интерфейсы (API), применяемые для создания дополнительной функциональности и реализации особенностей работы программного обеспечения за счет прямого обращения к функциональности базовых данных и исходного кода без модификации базовой системы. Это может быть выполнено с помощью привлечения профессиональных разработчиков и является затратным решением как с точки зрения разработки, так и с точки зрения сопровождения готового решения.
Модификация программного кода. Способ предусматривает прямую трансформацию исходного кода для добавления или изменения функциональности системы. Это может быть сделано производителем или пользователем и является самым дорогим и технически сложным методом.
Последствия конфигурирования и адаптации
Любые модификации имеют свои последствия— внесение изменений в готовое решение путем конфигурации и адаптации влияет на затраты, сроки внедрения, функционирование, обслуживание, модернизацию и поддержку продукта. Внедрение системы автоматизации будет отложено на время внесения изменений, причем финансовые потери будут определяться двумя факторами— увеличением затрат, необходимым для модификации продукта, и сдвигом сроков возврата инвестиций (ROI), на фоне того, что лицензии уже приобретены.
Рост операционных расходов и расходов на сопровождение зависит от сложности конфигурации и адаптации. Чем более существенные изменения вносятся в стандартную платформу ITSM, тем больше будут расходы на сопровождение на протяжении всего жизненного цикла продукта. Также нельзя игнорировать возникающую зависимость от качества поддержки адаптированного решения со стороны разработчиков уникального решения.
Адаптация— одна из самых часто упоминаемых причин сбоев в работе программного обеспечения. Технические сбои мешают максимально эффективно использовать решение, которое превращается в расходную часть (пассив), а не в актив. В бизнесе время— деньги, поэтому в результате адаптации программного обеспечения операционные расходы в расчете на звонок в службу поддержки зачастую будут расти, а не снижаться.
С одной стороны, инструментарий службы поддержки необходимо выбирать таким образом, чтобы можно было гарантировать постоянное соответствие этих служб меняющимся бизнес-требованиям. Однако и сами модификации, и их последующие изменения на протяжении всего жизненного цикла продукта также приводят к увеличению затрат. Кроме того, модификации напрямую влияют на поддержку продукта у производителя. У заказчика возникают сложности с поддержкой адаптированных решений, поскольку развитие готового продукта поставщиком не согласовывается с адаптированным решением.
Модернизация адаптивных решений, как правило, требует значительных усилий. Если производитель или внешний разработчик не учитывает необходимость последующих модернизаций, маловероятно, что все изменения инструментария, сделанные в результате конфигурации и адаптации, будут автоматически переноситься на новую версию. И когда эти модификации не сопровождаются необходимой документацией, вполне возможно, что придется проводить аудит всех адаптаций, прежде чем начать вручную переносить модификации в новую версию— а это достаточно длительный и дорогостоящий процесс. Масштаб такого проекта не следует недооценивать, и во многих случаях выгоднее заняться поиском на рынке альтернативных решений.
Когда необходимы изменения готового решения?
С точки зрения бизнеса, следует просто выделить нужную сумму на реализацию конкретной возможности службы поддержки. При этом самый надежный способ гарантировать, что расходы никогда не превысят ценности решения,— это убедиться, что вся функциональность реализована в готовом инструментарии. Не стоит рассчитывать на то, что готовый продукт будет отвечать всем требованиям, однако необходимо быть уверенным в том, что «небольшое количество жизненно важных» требований, на долю которых придется 80% всей пользы от продукта, можно получить без модификации. Важно четко представлять, какая функциональность имеется в исходном продукте, а что должно быть реализовано за счет конфигурации и адаптации. В тех случаях, когда это возможно, лучше выбрать инструментарий, в котором оставшиеся обязательные требования можно удовлетворить с помощью инструментов конфигурации, а не за счет адаптации. Это нужно для минимизации количества требований, выходящих за рамки готовой функциональности— известно, что формулировка «нам это нужно» на самом деле означает «было бы неплохо это иметь». Не каждое требование можно рассматривать как обязательное, поэтому необходимо, чтобы в компании была принята политика, в соответствии с которой все требования, предполагающие затратную адаптацию продукта, подтверждались с точки зрения их необходимости для бизнеса. Такая политика позволит минимизировать общую стоимость владения в течение жизненного цикла продукта. Важно задать себе два вопроса: насколько действительно нужна эта возможность и есть ли риск, что стоимость реализации этой функциональности превысит эффект от ее применения?
Каждое требование, которое может быть выполнено за счет использования функций готового продукта, «оплачивается» из суммы, потраченной на покупку лицензии, и существенно экономит общие затраты. Предположим, что инструментарий службы поддержки должен соответствовать 100 требованиям, 80 из которых выполняются в готовом решении, а 20 необходимо реализовать дополнительно. Пусть лицензионные затраты составляют 2000 долл. на пользователя в год, в таком случае стандартное требование в расчете на пользователя будет стоить 25 долл.
Предположим, что средние затраты на изменения составят: а) на реализацию одного требования с помощью конфигурации— 50 долл, что равняется примерно 2-4 часам работы администратора системы; б) на реализацию одного требования с помощью адаптации— 1 тыс. долл., что составляет примерно 1-2 дня работы разработчика системы. В таком случае, если 20 требований можно на 50% выполнить с помощью конфигурации, а на 50% с помощью адаптации, то вы можете добавить к общей сумме 500 долл. за изменения путем конфигурации и 10 тыс. долл. за изменения путем адаптации. Если у продукта 20 пользователей, и в течение первого года нет необходимости в дальнейших изменениях, то затраты за первый год (исключая расходы на услуги реализации) составят 50500 долл. против 40 тыс. Это на 25% больше, чем если бы готовое решение изначально соответствовало всем требованиям. Кроме того, при отсутствии должного управления, по мере увеличения срока использования продукта те изменения, которые внесены в результате его адаптации, могут вызвать экспоненциальный рост расходов.
Для каждого конкретного набора инструментальных средств необходимо выяснить, каким функциональным требованиям удовлетворяет готовое решение, а какие можно выполнить за счет конфигурации или адаптации. Стоит с осторожностью стремиться к тому, чтобы про созданное решение можно было сказать, что «наш продукт может делать все». Гибкость никогда не дается бесплатно. Также важно помнить, что серьезная адаптация решения может иметь далеко идущие последствия— это повлияет на отдачу от инвестиций на всех этапах жизненного цикла продукта, от реализации и использования до поддержки и модернизации. Необходимо расставить приоритеты требований с учетом их цены и пользы для бизнеса, а не в зависимости от того, кто выдвигает эти требования и насколько настойчиво. Как правило, 80% ценности инструментария службы поддержки приходится на 20% его функциональности. Стоит ли тратить 250% от стоимости готового решения на то, чтобы добиться выполнения оставшихся 20%?
Как избежать столь высоких затрат на модификацию стандартных решений, предлагаемых на рынке? Выход— использование продуктов «out-of-the-box», концепция разработки которых изначально опирается на стандарты, такие как ITIL.
ITIL как средство стандартизации
Решения, построенные по принципам ITIL, обладают следующими возможностями:
-
Изначальная интеграция всех основных процессов ITIL: управление инцидентами, изменениями, задачами, конфигурациями и сервисами. Процессы могут реализовываться поэтапно или развертываться в рамках полной инсталляции пакета, что избавляет от необходимости покупать дополнительно отдельные ITSM-модули.
-
Возможность встраивания сформулированных заказчиком бизнес-правил или специфических процессов в момент внедрения продукта, а также возможность их изменения без дополнительного кодирования.
-
Использование методологии ITIL в качестве основы позволяет продукту иметь функциональность, которая руководит пользователем во всех процессах, опираясь на наилучшие практические решения ITIL, но при этом дает возможность изменить эти «изначальные» процессы таким образом, чтобы удовлетворить специфические бизнес-требования организации.
Подобный комплексный подход к развитию и техническому сопровождению позволяют свести к минимуму затраты на конфигурацию и/или адаптацию готового решения. Желательно также, чтобы компания, принявшая решение о внедрении новых или совершенствованию уже существующих ИТ-процессов, получала доступ к лучшим практическим решениям по автоматизации управления и сопровождению ИТ в своей отрасли. Такой подход позволит избежать типовых ошибок и сэкономить время на решении известных проблем.
Одним из примеров реализации концепции «out-of-the-box» является предлагаемый компанией Axios Systems продукт assyst (см. рисунок), основанный на ITIL v3. Заказчику не нужно быть специалистом по ITIL, чтобы воспользоваться преимуществами процессного подхода и функциональностью assyst— это продукт, готовый к внедрению в организации и позволяющий свести к минимуму необходимость конфигурации и адаптации. Решение assyst изначально создавалось таким образом, чтобы его можно было использовать при постоянно изменяющихся бизнес-требованиях.
Рисунок. Интеграционная архитектура assyst
Специфические детали описания бизнес-среды каждой компании хранятся в центральной базе данных, что гарантирует согласованность и актуальность информации. Такая база разделена на блоки данных (Customer Service Groups), предназначенные для конкретных рабочих групп, что позволяет одной системе обслуживать единые ИТ процессы в различных подразделениях, или обслуживать отличающиеся ИТ подразделения разных компаний. Это дает преимущества для провайдеров сервисных услуг и позволяет предоставлять услуги аутсорсинга различных процессов для нескольких заказчиков одновременно. В решении изначально интегрированы процессы ITIL используются известные, опробованные заранее процедуры, шаблоны, формы и подпроцессы, что существенно снижает затраты на доработку системы.
Портал самообслуживания assystNET дает возможность конечным пользователям регистрироваться в системе через Web, сообщать о своих инцидентах и отслеживать процесс их решения. Благодаря этому экономятся ресурсы первой линии службы поддержки и увеличивается эффективность работы. Ключевой особенностью решения «out-of-the-box» является возможность настройки внешнего вида портала с помощью встроенных средств конфигурации без кодирования, возможность использования отдельного Web-интерфейса под каждого заказчика.
Возможности assyst по интеграции и обмену данными обеспечиваются благодаря специализированным модулям, адаптерам, коллекторам, шлюзам, позволяющим интегрировать решение IT Service Management assyst с любым внешним приложением или источником данных (см. рис.). Интеграционная платформа позволяет организовать любой способ обмена данными: одно- и двунаправленный, событийный, по расписанию, от самых простых вариантов запуска внешних приложений до глубокой интеграции приложений с помощью встроенного API. Assyst позволяет обмениваться релевантной информацией с другими ITSM-системами, внешними системами мониторинга и сбора информации об ИТ-инфраструктуре.
Хеерко Груневеген (heerco.groenewegen@axiossystems.com) — вице-президент по развитию бизнеса компании Axios Systems.
Особенности assyst
Успех применения систем типа Axios assyst определяется особенностями их адаптации и конфигурирования для нужд конкретного заказчика— без учета тонкостей российского ИТ-рынка вообще и сектора решений для организации и автоматизации служб технической поддержки, в частности, инвестиции в решения управления ИТ будут неэффективны.
Конфигурирование и адаптация программного обеспечения предполагают наличие у заказчика некоторого готового программного решения (системы), в той или иной степени отвечающего его требованиям по различным критериям: стоимость лицензий, стоимость внедрения, функционал, стоимость последующего сопровождения и т.п. Несмотря на то, что сегодня преобладает тенденция использования готовых решений, стоит помнить и о том, что у заказчика всегда есть выбор— использовать уже имеющееся решение (путем его конфигурации или адаптации) либо создать собственное, заказав его разработку своему ИТ-подразделению или обратившись к внешнему разработчику.
В секторе решений для организации служб технической поддержки, конечно, повсеместно используются готовые системные решения различной степени сложности и функциональности. Необходимо отметить, что данные решения состоят не только из выбора системы автоматизации для реализации требований заказчика и последующего ее внедрения, а еще включают в себя предварительное обследование, анализ, построение организационно-процессной части решения и формализацию требований к системе автоматизации. Безусловно, стандартом «де-факто» по построению ИТ-процессов и организации служб технической поддержки ИТ является сегодня библиотека ITIL, однако в ней нет четких требований и вариантов построения процессов. Предполагается, что заказчик самостоятельно или при помощи внешних консультантов выстроит процессы в соответствии со своими требованиями, рекомендациями ITIL, внутренней культурой и экспертизой организации. В этом случае вопрос выбора системы автоматизации остается важной и ответственной частью решения, который априори будет решаться с учетом действительно важных, отфильтрованных и ранжированных по приоритетам требований заказчика, дав ему возможность более свободно ориентироваться в различных системах, а также в вопросах сравнения подходов к внедрению систем (конфигурация или адаптация).
Продукт аssyst представляет собой сбалансированное решение, позволяющее при необходимости достаточно быстро автоматизировать процессы ITIL в службе технической поддержки ИТ за счет богатого функционала. В системе заложена большая вариативность и конфигурируемость автоматизируемых процессов, причем основная часть потенциальных вариантов конфигурации процессов взята из рекомендаций ITIL, и это снижает риски, возникающие при постановке задач и формализации требований к системе.
Георгий Ованесян (croc@croc.ru), руководитель направления технической поддержки и аутсорсинга компании Крок (Москва).
