ноябрь    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

показать все 

14.11.2024

Обновление BI.ZONE Secure DNS: гибкая настройка фильтрации и максимальная скорость

Читать далее 

14.11.2024

RED Security: в октябре количество DDoS-атак на ТЭК выросло в 3 раза

Читать далее 

14.11.2024

Falcongaze представила новую версию DLP-системы — SecureTower 7 Helium

Читать далее 

14.11.2024

ИСП РАН покажет результаты 30-ти лет работы на Открытой конференции в Москве

Читать далее 

08.11.2024

Юбилейная конференция ЭОС: ЭОС: 30 лет лидерства на рынке автоматизации документооборота и обсуждение актуальных трендов

Читать далее 

показать все 

22.11.2024

Тандем технологий – драйвер инноваций.

Читать далее 

21.11.2024

ИИ: маршрут не построен, но уже проектируется

Читать далее 

18.11.2024

Глеб Шкрябин: «Надежные и масштабируемые системы — основа стабильной работы бизнеса в условиях больших нагрузок»

Читать далее 

14.10.2024

Елена Ситдикова: «На разработчиках программного обеспечения для транспорта лежит большая ответственность перед пассажирами»

Читать далее 

11.10.2024

Технологический ИИ-арсенал

Читать далее 

13.06.2024

Взгляд в перспективу: что будет двигать отрасль информационной безопасности

Читать далее 

18.04.2024

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

Читать далее 

18.04.2024

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

Читать далее 

18.04.2024

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

Читать далее 

18.04.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. В этом стандарте приведены основные методики количественной оценки рисков, однако сразу следует заметить, что воспользоваться ими, например, на малом предприятии будет непросто. Это займет время, много ресурсов ипотребует специальных знаний.

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

В начало⇑

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

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