Полезное:
Как сделать разговор полезным и приятным
Как сделать объемную звезду своими руками
Как сделать то, что делать не хочется?
Как сделать погремушку
Как сделать так чтобы женщины сами знакомились с вами
Как сделать идею коммерческой
Как сделать хорошую растяжку ног?
Как сделать наш разум здоровым?
Как сделать, чтобы люди обманывали меньше
Вопрос 4. Как сделать так, чтобы вас уважали и ценили?
Как сделать лучше себе и другим людям
Как сделать свидание интересным?
Категории:
АрхитектураАстрономияБиологияГеографияГеологияИнформатикаИскусствоИсторияКулинарияКультураМаркетингМатематикаМедицинаМенеджментОхрана трудаПравоПроизводствоПсихологияРелигияСоциологияСпортТехникаФизикаФилософияХимияЭкологияЭкономикаЭлектроника
|
СВВ життєвого циклу ІТ-рішенняЯк було показано, тривалість життєвого циклу визначається шляхом зіставлення технологічної межі і формалізованих потреб бізнес-користувачів. Розглянемо тепер, яким образом оцінюються витрати на ІТ-рішення протягом його життєвого циклу. Витрати, зроблені протягом життєвого циклу ІТ-рішення, ми розділимо на дві групи: · витрати на супровід і адміністрування, оплачені простої користувачів. Ці витрати взаємозалежні; як було показано в розділі 1.2.2, вони визначаються на основі даних СУС, технічних можливостей ІС і параметрів самих ІТ-рішень. Прогноз потреб користувачів нетипових випадках слабко впливає на витрати цієї групи; · витрати на придбання і впровадження ІТ-рішення, а також на його наступну модернізацію. Визначаються на основі двох груп параметрів: зростання потреб користувачів і первісного масштабу рішення. Розглянемо ці дві групи докладніше. Вихідним пунктом для визначення витрат на супровід і адміністрування, а також втрат від оплачуваних простоїв користувачів є угода про рівень сервісу (СУС). З одного боку, СУС фіксує припустимі величини простоїв користувачів, з іншого боку - ресурси, що виділяються ІС для супроводу сервісів (включаючи адміністрування). При цьому припущення про невиконання СУС є несумісним з розумним плануванням: в цьому випадку ІС необхідно установити інші параметри СУС або по обсязі ресурсів, що виділяються або по параметрах сервісу. З цієї причини прогноз обсягу втрат від простоїв не повинний перевищувати обсяг, зазначений в СУС. Одночасно принцип консерватизму вимагає припускати максимально можливий розумний обсяг простоїв, тобто обсяг не менше зафіксованого в СУС. Підхід, заснований на СУС, можливий тільки у випадку зміни інфраструктури ІТ уже діючого сервісу (сервісів). Для знову створюваного сервісу (сервісів) прогноз оплачуваних простоїв необхідно складати на підставі попередньої оцінки бізнес-вимог. Вона може бути проведена: · за аналогією з подібними сервісами в інших підрозділах; · за аналогією з подібними сервісами інших підприємств; · на підставі даних бенчмаркінга, якщо такі доступні; · на підставі галузевих оглядів і оцінок і т.д. Таким чином, наближена оцінка прийнятного для бізнесу часу оплачених простоїв може бути отримана і для знову створюваного сервісу. Оцінка витрат на супровід і адміністрування виробляється аналогічно оцінці утрат від простоїв. Якщо розглянуте ІТ-рішення відноситься до існуючого сервісу, то провіз будується з обліком даних СУС Для знову створюваних сервісів доступна наближена оцінка витрат, одержувана тими ж способами, що й оцінка утрат від оплачуваних простоїв. Перейдемо до оцінки витрат другої групи. Якщо відомо динаміку потреб бізнес-сервісів у ресурсах інфраструктури ІТ, припустимі два крайніх шляхи відповідності цієї динаміки Перший полягає в тому, щоб підтримувати, параметри інфраструктури ИТ якнайближче до мінімально мислимих значень. Другий — у максимально можливому в межах, що допускаються бюджетом, наближенні параметрів інфраструктури ІТ до технологічної межі. На практиці звичайно спостерігається якийсь проміжний варіант між відзначеними крайностями. Співвідношення варіантів визначається наступними факторами: · політику постачальника в області цін на первісну конфігурацію устаткування і/або ПЗ, а також наступне нарощування цієї конфігурації; · графіка зростання потреб бізнес-сервісів у ресурсах ІТ; · технічними ризиками розглянутого рішення. Додамо короткий коментар до останнього пункту. За інших рівних умов більший технічний ризик, зв'язаний з ІТ рішенням, вимагає менших первісних витрат на його впровадження і великі витрати на його наступний розвиток. Тим самим можна звести до мінімуму фінансові ризики при даному рівні технічного ризику. З цієї причини графік нарощування ресурсів ІТ-рішення повинний не тільки мінімізувати приведену вартість платежів постачальникові, але і містити виправлення на ризик розглянутого рішення. Варто врахувати, що строгий вірогідний аналіз ризику в цій задачі практично неможливий. Така ситуація припускає два шляхи. Перший — експертна оцінка ризику. Другий — класифікація бізнес ситуацій по ступені технічного ризику і визначення виправлення на ризик відповідно до групи ризику, привласненої рішенню. Другий варіант типовий для більш високого рівня зрілості бізнесів-процесів ІС. Таким чином, ми визначили підходи до оцінки витрат на ІТ-рішення протягом його життєвого циклу. Подальший аналіз визначається співвідношенням планового обрію й оціненої на попередніх кроках тривалості життєвого циклу. Якщо тривалість життєвого циклу рішення перевершує плановий обрій ІС, аналіз на цьому завершується. В противному випадку проводиться оцінка витрат на впровадження ІТ-рішення наступного покоління, що повинне бути використане при виході за технологічну межу. Оцінка такого роду може бути тільки приблизною, однак і в такому виді вона представляє корисну інформацію про сукупні витрати на задоволення бізнес-вимог. Інакше будуть вибиратися рішення дешеві, але «короткоживучі», не враховуючих технологічних меж і необхідних витрат на заміну застарілого устаткування.
|