Поняття технологічної межі іт-рішення
Аналіз технологічних меж ІТ-рішень ми почнемо з простого графіка. Прокоментуємо рис. 2.8. Під результатом розуміється натуральний показник, що характеризує обсяг ресурсів, наданих рішенням. Це може бути, наприклад, продуктивність, обсяг оперативної пам'яті, пропускна здатність і т.д. Звичайно даний об'ємний показник збігається з фактором витрат відповідного ресурсу. Під витратами розуміються грошові кошти, витрачені на впровадження і/або модернізацію ІТ-рішення, необхідні для досягнення відповідного значення показника результату.
Рис. 2.8. Технологічна межа ІТ-рішення
Усі відомі на сьогоднішній день технології характеризуються S-образною, або логістичною, формою технологічної кривої. Ліва її частина іменується Р. Фостером кривою навчання, права - кривою спадної віддачі. Всяка S-образна крива характеризується технологічною межею - значенням показника результату, що не може бути перевищене в рамках даної технології.
Розглянемо деякі типові приклади технологічних меж для ІТ-рішень:
межу продуктивності центрального процесора;
граничний обсяг оперативної пам'яті;
граничний обсяг дискового простору;
гранична пропускна здатність системної шини;
гранична пропускна здатність активного мережного устаткування і каналів зв'язку;
граничне число одночасно працюючих користувачів СУБД
або бізнес-додатку;
граничне число транзакцій за секунду - також для СУБД або бізнес-додатку.
Облік технологічної межі при виборі ІТ-рішень здійснюється наступним способом. Оцінюються перспективні потреби бізнесів-користувачів, бажа-но – з розбивкою по роках. Служби планування сервісів і керування ресурсами зіставляють ці потреби з наявними ресурсами ІТ-інфраструктури. На основі такого порівняння приблизно визначається момент, коли технологічна межа інфраструктури ІТ (або, частіше, окремих її елементів) буде перекритий потребами бізнесу. У підсумку розраховується тривалість життєвого циклу ІТ-рішень.
На практиці основу прогнозу перспективних потреб бізнесу складає портфель затверджених бізнесів-проектів. При більш тривалих термінах прогнозування (3-5 років) дані портфеля проектів доповнюються даними ІТ-стратегии підприємства.
Таким чином, технологічні межі використовуваних ІТ-рішень відслідковуються в рамках процесів блоку планування і керування сервісів. Основний алгоритм контролю - зіставлення технологічних меж ІТ-рішень і бізнес-вимог, сформульованих у формі портфеля бізнес-проектів і ІТ-стратегії підприємства.
Свв життєвого циклу іт-рішення
Як було показано, тривалість життєвого циклу визначається шляхом зіставлення технологічної межі і формалізованих потреб бізнес-користувачів. Розглянемо тепер, яким образом оцінюються витрати на ІТ-рішення протягом його життєвого циклу. Витрати, зроблені протягом життєвого циклу ІТ-рішення, ми розділимо на дві групи:
витрати на супровід і адміністрування, оплачені простої користувачів. Ці витрати взаємозалежні; як було показано в розділі 1.2.2, вони визначаються на основі даних СУС, технічних можливостей ІС і параметрів самих ІТ-рішень. Прогноз потреб користувачів нетипових випадках слабко впливає на витрати цієї групи;
витрати на придбання і впровадження ІТ-рішення, а також на його наступну модернізацію. Визначаються на основі двох груп параметрів: зростання потреб користувачів і первісного масштабу рішення.
Розглянемо ці дві групи докладніше.
Вихідним пунктом для визначення витрат на супровід і адміністрування, а також втрат від оплачуваних простоїв користувачів є угода про рівень сервісу (СУС). З одного боку, СУС фіксує припустимі величини простоїв користувачів, з іншого боку - ресурси, що виділяються ІС для супроводу сервісів (включаючи адміністрування). При цьому припущення про невиконання СУС є несумісним з розумним плануванням: в цьому випадку ІС необхідно установити інші параметри СУС або по обсязі ресурсів, що виділяються або по параметрах сервісу. З цієї причини прогноз обсягу втрат від простоїв не повинний перевищувати обсяг, зазначений в СУС. Одночасно принцип консерватизму вимагає припускати максимально можливий розумний обсяг простоїв, тобто обсяг не менше зафіксованого в СУС.
Підхід, заснований на СУС, можливий тільки у випадку зміни інфраструктури ІТ уже діючого сервісу (сервісів). Для знову створюваного сервісу (сервісів) прогноз оплачуваних простоїв необхідно складати на підставі попередньої оцінки бізнес-вимог. Вона може бути проведена:
за аналогією з подібними сервісами в інших підрозділах;
за аналогією з подібними сервісами інших підприємств;
на підставі даних бенчмаркінга, якщо такі доступні;
на підставі галузевих оглядів і оцінок і т.д.
Таким чином, наближена оцінка прийнятного для бізнесу часу оплачених простоїв може бути отримана і для знову створюваного сервісу.
Оцінка витрат на супровід і адміністрування виробляється аналогічно оцінці утрат від простоїв. Якщо розглянуте ІТ-рішення відноситься до існуючого сервісу, то провіз будується з обліком даних СУС Для знову створюваних сервісів доступна наближена оцінка витрат, одержувана тими ж способами, що й оцінка утрат від оплачуваних простоїв.
Перейдемо до оцінки витрат другої групи. Якщо відомо динаміку потреб бізнес-сервісів у ресурсах інфраструктури ІТ, припустимі два крайніх шляхи відповідності цієї динаміки Перший полягає в тому, щоб підтримувати, параметри інфраструктури ИТ якнайближче до мінімально мислимих значень. Другий — у максимально можливому в межах, що допускаються бюджетом, наближенні параметрів інфраструктури ІТ до технологічної межі. На практиці звичайно спостерігається якийсь проміжний варіант між відзначеними крайностями. Співвідношення варіантів визначається наступними факторами:
політику постачальника в області цін на первісну конфігурацію устаткування і/або ПЗ, а також наступне нарощування цієї конфігурації;
графіка зростання потреб бізнес-сервісів у ресурсах ІТ;
технічними ризиками розглянутого рішення.
Додамо короткий коментар до останнього пункту. За інших рівних умов більший технічний ризик, зв'язаний з ІТ рішенням, вимагає менших первісних витрат на його впровадження і великі витрати на його наступний розвиток. Тим самим можна звести до мінімуму фінансові ризики при даному рівні технічного ризику. З цієї причини графік нарощування ресурсів ІТ-рішення повинний не тільки мінімізувати приведену вартість платежів постачальникові, але і містити виправлення на ризик розглянутого рішення. Варто врахувати, що строгий вірогідний аналіз ризику в цій задачі практично неможливий. Така ситуація припускає два шляхи. Перший — експертна оцінка ризику. Другий — класифікація бізнес ситуацій по ступені технічного ризику і визначення виправлення на ризик відповідно до групи ризику, привласненої рішенню. Другий варіант типовий для більш високого рівня зрілості бізнесів-процесів ІС.
Таким чином, ми визначили підходи до оцінки витрат на ІТ-рішення протягом його життєвого циклу. Подальший аналіз визначається співвідношенням планового обрію й оціненої на попередніх кроках тривалості життєвого циклу. Якщо тривалість життєвого циклу рішення перевершує плановий обрій ІС, аналіз на цьому завершується. В противному випадку проводиться оцінка витрат на впровадження ІТ-рішення наступного покоління, що повинне бути використане при виході за технологічну межу. Оцінка такого роду може бути тільки приблизною, однак і в такому виді вона представляє корисну інформацію про сукупні витрати на задоволення бізнес-вимог. Інакше будуть вибиратися рішення дешеві, але «короткоживучі», не враховуючих технологічних меж і необхідних витрат на заміну застарілого устаткування.