Главная Случайная страница


Полезное:

Как сделать разговор полезным и приятным Как сделать объемную звезду своими руками Как сделать то, что делать не хочется? Как сделать погремушку Как сделать так чтобы женщины сами знакомились с вами Как сделать идею коммерческой Как сделать хорошую растяжку ног? Как сделать наш разум здоровым? Как сделать, чтобы люди обманывали меньше Вопрос 4. Как сделать так, чтобы вас уважали и ценили? Как сделать лучше себе и другим людям Как сделать свидание интересным?


Категории:

АрхитектураАстрономияБиологияГеографияГеологияИнформатикаИскусствоИсторияКулинарияКультураМаркетингМатематикаМедицинаМенеджментОхрана трудаПравоПроизводствоПсихологияРелигияСоциологияСпортТехникаФизикаФилософияХимияЭкологияЭкономикаЭлектроника






СВВ життєвого циклу ІТ-рішення





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

· витрати на супровід і адміністрування, оплачені простої користувачів. Ці витрати взаємозалежні; як було показано в розділі 1.2.2, вони визначаються на основі даних СУС, технічних можливостей ІС і параметрів самих ІТ-рішень. Прогноз потреб користувачів нетипових випадках слабко впливає на витрати цієї групи;

· витрати на придбання і впровадження ІТ-рішення, а також на його наступну модернізацію. Визначаються на основі двох груп параметрів: зростання потреб користувачів і первісного масштабу рішення.

Розглянемо ці дві групи докладніше.

Вихідним пунктом для визначення витрат на супровід і адміністрування, а також втрат від оплачуваних простоїв користувачів є угода про рівень сервісу (СУС). З одного боку, СУС фіксує припустимі величини простоїв користувачів, з іншого боку - ресурси, що виділяються ІС для супроводу сервісів (включаючи адміністрування). При цьому припущення про невиконання СУС є несумісним з розумним плануванням: в цьому випадку ІС необхідно установити інші параметри СУС або по обсязі ресурсів, що виділяються або по параметрах сервісу. З цієї причини прогноз обсягу втрат від простоїв не повинний перевищувати обсяг, зазначений в СУС. Одночасно принцип консерватизму вимагає припускати максимально можливий розумний обсяг простоїв, тобто обсяг не менше зафіксованого в СУС.

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

· за аналогією з подібними сервісами в інших підрозділах;

· за аналогією з подібними сервісами інших підприємств;

· на підставі даних бенчмаркінга, якщо такі доступні;

· на підставі галузевих оглядів і оцінок і т.д.

Таким чином, наближена оцінка прийнятного для бізнесу часу оплачених простоїв може бути отримана і для знову створюваного сервісу.

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

Перейдемо до оцінки витрат другої групи. Якщо відомо динаміку потреб бізнес-сервісів у ресурсах інфраструктури ІТ, припустимі два крайніх шляхи відповідності цієї динаміки Перший полягає в тому, щоб підтримувати, параметри інфраструктури ИТ якнайближче до мінімально мислимих значень. Другий — у максимально можливому в межах, що допускаються бюджетом, наближенні параметрів інфраструктури ІТ до технологічної межі. На практиці звичайно спостерігається якийсь проміжний варіант між відзначеними крайностями. Співвідношення варіантів визначається наступними факторами:

· політику постачальника в області цін на первісну конфігурацію устаткування і/або ПЗ, а також наступне нарощування цієї конфігурації;

· графіка зростання потреб бізнес-сервісів у ресурсах ІТ;

· технічними ризиками розглянутого рішення.

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

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

 

Date: 2015-09-18; view: 375; Нарушение авторских прав; Помощь в написании работы --> СЮДА...



mydocx.ru - 2015-2024 year. (0.006 sec.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав - Пожаловаться на публикацию