Календарь мероприятий
октябрь 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 | 31 | | | |
показать все
Новости партнеров
«Киберарена»: «Газинформсервис» запускает новый формат киберсоревнований
Читать далее
IV-й ЭТАП КулибИТ -2024
Читать далее
Состоялась церемония гашения юбилейной почтовой открытки, выпущенной к 30-летию домена .RU
Читать далее
На GIS DAYS: всё, что нужно знать о надёжной электронной подписи
Читать далее
РДТЕХ и «Хи-квадрат» начали массовое обучение ИТ-специалистов технологии импортозамещения Oracle Apex / Oracle Forms
Читать далее
показать все
Статьи
Чем страшен ИИ, и с чем его едят
Читать далее
Готов ли рынок АСУ ТП к переменам?
Читать далее
Отрыв длиной в год. Российские ИИ-решения незначительно уступают иностранным аналогам
Читать далее
Лейсан Чистая: «КулибИТ для каждого из нас это больше, чем просто проект – это наша миссия»
Читать далее
Оптимизация продаж лизинговых услуг с ИИ для ГК Альфа-Лизинг с платформой ValueAI
Читать далее
Взгляд в перспективу: что будет двигать отрасль информационной безопасности
Читать далее
5 способов повысить безопасность электронной подписи
Читать далее
Как искусственный интеллект изменит экономику
Читать далее
Неочевидный САПР: выход ПО за рамки конструкторской деятельности
Читать далее
Скоро некому будет делать сайты и заниматься версткой
Читать далее
показать все
|
Экономическое убеждение и риск‑менеджмент «на коленке». Как наглядно убедить руководство
Главная /
Архив номеров / 2016 / Выпуск №02 (55) / Экономическое убеждение и риск‑менеджмент «на коленке». Как наглядно убедить руководство
Рубрика:
Экономика ИТ
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
Алексей Лагутенков, 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. В этом стандарте приведены основные методики количественной оценки рисков, однако сразу следует заметить, что воспользоваться ими, например, на малом предприятии будет непросто. Это займет время, много ресурсов ипотребует специальных знаний.
С другой стороны, тема эта чрезвычайно интересная, и если есть желание развить у себя соответствующий навык, то в дальнейшем рынок труда наверняка оценит ваши усилия. В начало⇑
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
Комментарии отсутствуют
Комментарии могут отставлять только зарегистрированные пользователи
|
Вакансии на сайте Jooble
|