Конфігурація і адаптацію програмного забезпечення за змістом часто путают- обидва терміни нерідко використовують як синоніми, коли мова йде про модифікації ПО для його відповідності специфічним вимогам замовника. Програмне забезпечення можна назвати конфігурованим, якщо його можна налаштувати через стандартні інтерфейси без програмування додаткових функцій і / або без зміни вихідного коду програми. Якщо вимоги до системи не можна задовольнити без програмування або зміни вихідного коду, то програмне забезпечення прийнято називати адаптованим.

Важливим аспектом, що відрізняє конфігурація від адаптації, є істотна різниця в необхідних ресурсах і рівні компетенції персоналу для досягнення потрібного результату. Адаптація готового рішення вимагає значно більше ресурсів, причому не тільки в момент внесення змін, але і протягом всього життєвого циклу рішення.

Можливості системи автоматизації служби підтримки визначаються ринковим спросом- якщо попит на певну можливість продукту досить високий, виробники будуть таку можливість розробляти для своїх рішень, і вона дуже швидко набуде поширення на ринку як «стандартна» функція; а якщо вимога не користується масовим попитом, то відповідні функції розробляються таким чином, щоб їх можна було підтримувати за допомогою додаткових змін і налаштувань, що зажадає від користувача додаткових витрат. Якщо ж вимоги до функціональності унікальні, то малоймовірно, що користувач зможе знайти вже наявне рішення, тому реалізація буде істотно відрізнятися від можливостей готового (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-системами, зовнішніми системами моніторингу і збору інформації про ІТ-інфраструктурі.

Хеерко Груневег ( [email protected] ) - віце-президент з розвитку бізнесу компанії Axios Systems.

особливості assyst

Успіх застосування систем типу Axios assyst визначається особливостями їх адаптації та конфігурації для потреб конкретного заказчіка- без урахування тонкощів російського ІТ-ринку взагалі і сектора рішень для організації та автоматизації служб технічної підтримки, зокрема, інвестиції в рішення управління ІТ будуть неефективні.

Конфігурація и адаптація програмного забезпечення пріпускають наявність у замовника Деяк готового програмного решение (системи), в тій чи іншій мірі відповідає его Вимоги за різнімі крітеріямі: ВАРТІСТЬ ліцензій, ВАРТІСТЬ Впровадження, функціонал, ВАРТІСТЬ Подальшого супроводу и т.п. Незважаючи на те, що сьогодні переважає тенденція використання готових рішень, варто пам'ятати і про те, що у замовника завжди є вибір-використовувати вже наявне рішення (шляхом його конфігурації або адаптації) або створити власне, замовивши його розробку своєму ІТ-підрозділу або звернувшись до зовнішньому розробнику.

У секторі рішень для організації служб технічної підтримки, звичайно, повсюдно використовуються готові системні рішення різного ступеня складності і функціональності. Необхідно відзначити, що дані рішення складаються не тільки з вибору системи автоматизації для реалізації вимог замовника і подальшого її впровадження, а ще включають в себе попереднє обстеження, аналіз, побудова організаційно-процесної частини рішення і формалізацію вимог до системи автоматизації. Безумовно, стандартом «де-факто» з побудови ІТ-процесів і організації служб технічної підтримки ІТ є сьогодні бібліотека ITIL, проте в ній немає чітких вимог і варіантів побудови процесів. Передбачається, що замовник самостійно або за допомогою зовнішніх консультантів вибудує процеси в відповідності зі своїми вимогами, рекомендаціями ITIL, внутрішньою культурою та експертизою організації. У цьому випадку питання вибору системи автоматизації залишається важливою і відповідальною частиною рішення, який апріорі буде вирішуватися з урахуванням дійсно важливих, відфільтрованих і ранжируваних за пріоритетами вимог замовника, давши йому можливість більш вільно орієнтуватися в різних системах, а також в питаннях порівняння підходів до впровадження систем (конфігурація або адаптація).

Продукт аssyst є збалансоване рішення, що дозволяє при необхідності досить швидко автоматизувати процеси ITIL в службі технічної підтримки ІТ за рахунок багатого функціоналу. В системі закладена велика варіативність і конфігурованість автоматизованих процесів, причому основна частина потенційних варіантів конфігурації процесів взята з рекомендацій ITIL, і це знижує ризики, що виникають при постановці завдань і формалізації вимог до системи.

Георгій Ованесян ( [email protected] ), Керівник напрямку технічної підтримки і аутсорсингу компанії Крок (Москва).