апрель    2024

Пн	Вт	Ср	Чт	Пт	Сб	Вс
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

показать все 

22.04.2024

Сообщество цифровых управленцев «я-ИТ-ы» проводит ЗАКРЫТУЮ встречу в рамках выставки «Связь-2024»!

Читать далее 

18.04.2024

Ассоциация разработчиков «Отечественный софт» отметила 15-летие

Читать далее 

17.04.2024

РДТЕХ представил Технологическую карту российского ПО 2023

Читать далее 

16.04.2024

RAMAX Group получила партнерский статус уровня Gold по продукту Tarantool

Читать далее 

показать все 

18.04.2024

5 способов повысить безопасность электронной подписи

Читать далее 

18.04.2024

Как искусственный интеллект изменит экономику

Читать далее 

18.04.2024

Неочевидный САПР: выход ПО за рамки конструкторской деятельности

Читать далее 

18.04.2024

Скоро некому будет делать сайты и заниматься версткой

Читать далее 

18.04.2024

Цифровая трансформация в энергетике: как запустить проект с максимальным финансовым эффектом?

Читать далее 

05.04.2024

Мотивируй, не то проиграешь!

Читать далее 

22.03.2024

В 2024 году в России и мире вырастут объемы применения AR/VR 

Читать далее 

25.02.2024

Цифровые технологии: надежды и риски

Читать далее 

05.02.2024

Будут ли востребованы услуги технической поддержки софта Oracle в России в ближайшие годы?  

Читать далее 

31.01.2024

Здания с признаками интеллекта. Как Сергей Провалихин автоматизирует дома и производства

Читать далее 

показать все 

Главная / Архив номеров / 2016 / Выпуск №02 (55) / Экономическое убеждение и риск‑менеджмент «на коленке». Как наглядно убедить руководство

Рубрика: Экономика ИТ

Алексей Лагутенков, MBA Kingston University UK, ITSM Manager, MCSE+I, MCSE:S:M, MCDBA, MCDST

Экономическое убеждение и риск-менеджмент «на коленке»
Как наглядно убедить руководство

Когда стоит, а когда не стоит рассчитывать экономическую эффективность проектов? Как с минимальными усилиями оценить риски проекта и донести эту информацию доначальства?

Я сейчас сделаю странное заявление: айтишники не любят математику и не любят считать; «железячники», программисты, проджект-менеджеры и архитекторы – все не любят считать. Многие скажут: «Бред! На работе каждый день приходится что-то считать!» Да, приходится. Но по заранее известному алгоритму, в котором не больше двух-трех арифметических действий, либо в Excel, где формулы уже заранее забиты кем-то. Провести полный расчет чего-либо с нуля и до самого результата, с разработкой собственной методики способны единицы.

Предвидя возражения и обвинения, сразу замечу: а это, собственно, и не так плохо, что большинство из нас не умеют обсчитывать какие-то сложные вещи. В реальной жизни математические абстракции нужны очень редко. Кто после школы хоть раз вспомнил и применил тригонометрические формулы? Тангенсы, котангенсы всякие? Больше чем уверен,что практически никто. Кто после института хотя бы раз самостоятельно нарисовал графики функций? Таких единицы, и скорее всего это продавцы ИТ-решений, которые демонстрировали клиентам экспоненциальный рост производительности при линейных затратах, причем делали это без конкретных цифр.

Особенность долгой работы в ИТ-отрасли заключается в том, что человек начинает мыслить шаблонами. В случае непонятностей искать «HOW TO» в Google или на хелпдеске вендора. Возникающая проблема чаще всего не уникальна и уже решена кем-то раньше. Это сильно облегчает жизнь.

Почти 700 лет назад величайший редукционист, английский монах-францисканец, философ-номиналист Уильям Оккам провозгласил принцип: «Не умножай сущностей безнеобходимости», и до сих пор это один из базовых научных тезисов. Как это можно применить к тому, что сказано выше, и связать с ИТ? Приблизительно можно перефразировать так: «избегай сложного там, где можно обойтись простым».

О чем пойдет разговор? Об оценке экономической эффективности проектов. Только в этот раз мы поговорим не о самих расчетах, а о том, как бы поменьше работать и чтоб начальство за это нас исключительно хвалило.

В чем суть исследуемой проблемы? В вашей компании решено запускать реализацию ИТ-проекта. Предположим, вы единственный системный инженер на предприятии или даже вы– ИТ-директор c департаментом в 50 человек – неважно. В один прекрасный или не очень день вас ставят перед фактом, что время пришло и скоро наша компания начинает работатьнад проектом.

Смысл этой статьи в том, чтобы постараться получить максимальные личные и карьерные выгоды от внедрения проекта. Сразу огорчу: нет, речь не пойдет о схемах откатов или отом, как обналичить средства, выделенные на проект.

Поговорим о том, как принять самое деятельное участие в проекте, выделиться в глазах начальства, если ваша роль во внедрении ИТ-решения минимальна.

Для начала рассмотрим фреймворк (см. рис. 1), который полезен скорее для внутреннего пользования, чем для демонстрации начальству. Как показывает опыт, многие айтишники почему-то не понимают или не хотят понимать базовых карьерных вещей, о которых повествует эта простенькая схема.

Рисунок 1. Как принять решение о необходимости экономической оценки проекта

Смысл данного фреймворка в том, чтобы четко понимать, от кого исходит инициатива внедрения проекта, и только после этого осознания предпринимать какие-то шаги.

«Инициатива сверху» (Initiative from Top, IFT) означает, что проект внедряется по желанию высшего руководство (CEO, CFO, CDO, совета директоров или собственника бизнеса). Втаком случае вряд ли стоит соваться с инициативой по оценке экономической эффективности внедряемого решения. Это может дорого обойтись в карьерном плане. Начальство умнее, начальство лучше знает, и, кроме того, у начальства могут быть совершенно свои, недекларируемые, цели внедрения, которые вам неизвестны. Поэтому в случае инициативы сверху в большинстве случаев не стоит даже пытаться предлагать свои услуги по оценке решения. В данном случае риск от внедрения решения целиком лежит на руководстве. Конечно, есть риск, что в случае неудачного внедрения во всем обвинят местный ИТ-отдел, но, как правило, до такого самодурства доходит редко.

«Инициатива снизу» (Initiative from Down, IFD) – тот случай, когда инициатива исходит от вас как от директора по ИТ или ИТ-инженера. Здесь вполне можно выделиться ипосчитать TCO (Total Cost Ownership) предлагаемого решения и сравнить его с ТСО текущей ситуации.

Разумеется, ТСО предлагаемого решения должно быть меньше, если вдруг кому-то неочевидно. Если ИТ-проект связан с генерацией входящего денежного потока, то аллилуйя! Вам повезло: есть шанс показать свой исключительный талант, поскольку расчет можно красиво оформить доходным методом в виде ROI, с применением ставки дисконтирования ипроверкой результатов с помощь NPV. Самое главное, чтобы ROI был положительным, а NPV – больше нуля.

Помните о горизонтах планирования доходного метода: то, что не прибыльно в течение трех лет, может стать прибыльным при более широком горизонте, например, в течение пяти лет. Самое главное, не переусердствуйте в обоснованиях. Если проект, выглядящий на бумаге блестяще, не принесет компании ни копейки от того, что обещали лично вы, то стоит заранее подумать, насколько вам нравилось работать именно в этой компании.

«Инициатива снаружи» (Initiative from Outside, IFO) – это когда в компанию приглашают ИТ-бизнес-консультантов (хотя, честно говоря, гораздо чаще их никто не приглашает, онисами приходят). Если в первых двух случаях в лояльности руководства и ИТ-персонала компании сомневаться не приходилось (хотя бы чисто теоретически), то в случае работников посторонней организации следует включить режим параноидальных сомнений. Основная цель любой сторонней организации – посадить вашу компанию на «денежный насос», тоесть начать хорошую жизнь за счет вашего предприятия. В этом случае до начальства следует донести мысль о расчетах TCO или ROI, а также тщательной перепроверке таких расчетов, если они представлены сторонней фирмой.

Теперь перейдем к вспомогательной части оценки абстрактного ИТ-проекта, а именно к управлению рисками проекта. Предположим, вы предложили внедрить некое Open ERP-решение. Руководство в восторге. Не надо тратить тонны долларов и евро на покупку лицензий, при этом вся деятельность будет вестись в одной программе, а это прозрачные отчеты, постоянно доступные любые документы, права доступа и т.д. Это начальство оценило. Но когда, например, вы предлагаете купить вместо одного сервера два одинаковых идобавить еще к ним систему бэкапа, это может вызвать вопрос: «Зачем же такие затраты? Ведь так все хорошо начиналось!»

Кроме обоснования внедрения некоего ИТ-решения, вам придется заодно обосновать простейшее управление рисками проекта.

Предположим такую ситуацию. Вы пришли работать в компанию, где у всего персонала шикарные дорогие ноутбуки. Самый лучший и дорогой, естественно, у директора. В товремя как сайт компании, база данных и документооборот хранятся на стареньком самодельном десктопе с единственным жестким диском. Когда-то давно некий айтишник настроил им все это компьютерное хозяйство и по каким-то причинам уволился. Система продолжает работать и за все это время чудесным образом ни разу не упала. Естественное, что улюбого нормального системного инженера от такого вопиющего безрассудства начинают шевелиться волосы на голове, но на словах что-то донести до начальства бывает тяжело. Система столько времени работает, и претензий ни разу не было. Зачем что-то менять? На помощь придет презентация с приведенными ниже графиками (см. рис. 2).

Рисунок 2. Сопоставление рисков отказа оборудования, времени простоя оборудования и затрат на нейтрализацию этих двух факторов

Для начала следует объяснить начальству понятие уровня «допустимого риска» на предприятии. Уровень допустимого риска показан на графике 1. Смысл его понятия в следующем: предположим, весь спектр ИТ-процессов на предприятии дублируется на бумаге. Существуют база данных и одновременно бумажный архив с документами, где содержится та же самая информация. Любой работник в состоянии как напечатать любой документ с помощью компьютера, так и создать его же от руки. В случае аварии на главном и единственном сервере бизнес компании вообще никак не пострадает и продолжит работать в штатном режиме.

На графике 1 это участок от начала координат до точки А. Затраты на нейтрализацию риска отказа оборудования на данном участке графика столь незначительны, что ими можно пренебречь. Это означает, что компании, в общем-то, плевать, работают ее сервер и ИТ-инфраструктура или нет. Ситуация, конечно, труднопредставляемая и возможная в основном всередине 1990-х годов.

На участке А-В происходит перелом. Бизнесу компании становится небезразлично исправное функционирование ИТ. Но в повышение надежности работы серверов и всего такого прочего необходимо вкладывать деньги.

Другой неприятный факт в том, что никакой прямой экономической выгоды это не принесет. Поэтому для улучшения доступности ИТ-инфраструктуры покупается все самое дешевое. Тем не менее сбои функционирования оборудования наносят все больший ущерб бизнесу, и начинаются финансовые вливания в защиту ИТ-инфраструктуры.

В точке В на предприятии внедрены процессы ITIL, в частности Continuity и Availability-менеджмент. Все электропитание задублировано дизель-генераторами, оборудование объединено в кластеры, а ЦОДы дублируют друг друга в географически отдаленных друг от друга областях, дабы защититься от наводнений, землетрясений, пожаров итеррористических актов. Бизнесу в таком случае может нанести ущерб разве что падение метеорита или атака инопланетян. То есть в точке В дальнейшее наращивание инвестиций взащиту ИТ-инфраструктуры бессмысленно.

Именно поэтому после точки В можно наблюдать линейную зависимость между уровнем риска и инвестициями. Дублирующий четырехнодовый кластер, конечно же, надежнее двухнодового, но вероятность того, что эти возможности кластера когда-нибудь пригодятся, практически нулевая.

Второй график показывает время простоя оборудования и связан с графиком уровня допустимого риска. От начала координат до точки С начальству не важна ИТ- инфраструктура. Компьютеры могут простаивать сколько угодно. В точке С, соответствующей точке А на графике 1, происходит перелом мышления. Теперь компьютеры важны и нужны. На их защиту начинают тратиться. Затраты имеет смысл наращивать вплоть до точки D (точка В на графике 1). После D дальнейшее увеличение затрат не приносит экономической пользы.

Как использовать эти графики? Во-первых, с их помощью можно убедительно показать, что вообще всех рисков избежать невозможно, вернее, возможно, но затраты при этом будут стремиться к бесконечности. Во-вторых, руководству можно наглядно объяснить, что совсем затрат избежать не удастся. Оптимально выбрать участок между точками А и В или С иD (что то же самое).

Разумеется, кроме «риска отказа оборудования», на графики можно подставить любую другую сущность, которая подходит именно вашему проекту.

Предположим, что нам удалось убедить начальство в необходимости затрат, но возникает вопрос: как вычислить эти самые точки на графиках? Ответ на этот вопрос существует, нолучше постараться обосновать все качественно (не количественно), мотивируя это тем, что расчеты сложны и нашему небольшому предприятию такая сложность совсем ни к чему.

Точный расчет произвести можно, но это в чистом виде зона ответственности риск-менеджмента и стандарта ISO/IEC 31010:2009. В этом стандарте приведены основные методики количественной оценки рисков, однако сразу следует заметить, что воспользоваться ими, например, на малом предприятии будет непросто. Это займет время, много ресурсов ипотребует специальных знаний.

С другой стороны, тема эта чрезвычайно интересная, и если есть желание развить у себя соответствующий навык, то в дальнейшем рынок труда наверняка оценит ваши усилия.

В начало⇑

Комментарии отсутствуют

Комментарии могут отставлять только зарегистрированные пользователи