Интересно для всех

Тимоти Чоу

Почему информационные технологии стоят так много?
И что можно с этим поделать?
(Why Does <IT> Cost So Much?
And What Can You Do About It?
by Timothy Chou)

Источник: журнал Profit: Oracle's E-Business Magazine, no.1, 2004, рубрика “АУТСОРСИНГ”, http://www.oracle.com/oramag/profit/04-feb/p14outsourcing.html

Предлагаемая статья адаптирована для журнала Profit: Oracle's E-Business Magazine по материалам готовящейся к печати новой книги президента компании Oracle Outsourcing Тимоти Чоу “Next-Generation Outsourcing: Software as a Service”. (Аутсорсинг следующего поколения: программное обеспечение как сервис). Чоу – ветеран Oracle с шестилетним стажем – написал про аутсорсинг следующего поколения, чтобы предложить руководителям и бизнес-менеджерам альтернативу управлению и поддержанию систем информационных технологий, от которых так сильно зависят их компании. В этой главе своей книги Чоу помещает затраты на ИТ в контекст бизнес-императивов и предлагает предприятиям перейти от режима обслуживания систем к инновациям.

Двадцать пять лет назад только самые крупные предприятия в своем ежедневном бизнесе полагались на технологии. Сегодня каждая компания – открытая или частная; малая, средняя или крупная; национальная или международная – использует ИТ в клиентских частях приложений (front office), в выполняющихся на сервере приложениях, реализующих логику системы (back office), и в Интернете.

Поразительное увеличение роли ИТ непосредственно коррелирует с увеличением количества средств, затраченных на ИТ. Затраты взлетели, и руководители информационных подразделений (CIO), возлагающие ответственность за это на ИТ-стратегии и управление, наконец-то были услышаны. Журнал CIO, публикующий материалы для топ-профессионалов в области ИТ, сообщил в опубликованном в декабре 2002 года опросе CIO, что 67 процентов CIO назвали сокращение стоимости ИТ своим бизнес-приоритетом номер 1.

Безумие обслуживания

Чтобы понять, почему повышаются затраты, вы должны понять, как расходуются бюджеты на ИТ. Вообще говоря, сегодня бюджеты ИТ составляют от 1 до 10 процентов полного дохода корпорации. Лучшие ИТ-эксперты пришли к выводу, что 78 процентов бюджета ИТ расходуется только на управление имеющейся системой и инфраструктурами программного обеспечения. В 2001 году Gartner Group – всемирно известная аналитическая фирма, отслеживающая высокотехнологичный рынок – издала отчет, в котором подвела итоги типичного бюджета ИТ (см. рисунок 1).

Рисунок 1: Какая часть вашего бюджета ИТ уходит на обслуживание?

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

Таблица 1: Оценка сценариев (цифры в долларах) обслуживания ИТ (на ИТ - 1% полного дохода, из которых 78% - поддержка имеющихся систем).

Суммы в долларах просто огромны. Даже при консервативной оценке расходы этих восьми компаний на управление сложившейся у них вычислительной инфраструктурой превосходят 1 миллиард долларов США в год.

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

Почему настолько дорога поддержка имеющихся систем? И сколько она должна стоить? Согласно Gartner Group: "Заказчики могут ежегодно расходовать на владение и управление своими приложениями суммы, которые могут в четыре раза превышать стоимость их лицензий на программное обеспечение". Рассмотрим последствия этого утверждения. Предположите, что вы купили программное обеспечение за $500 000. При четырехкратном превышении цены покупки операционные затраты составят 2 миллиона долларов в год. Через пять лет эксплуатации эти расходы составят 10 миллионов долларов. Так что компания принимает решение стоимостью не $500 000. На самом деле это решение стоит 10.5 миллионов долларов.

Почему затраты являются такими астрономическими? Эми Мизорас (Amy Mizoras), ведущий аналитик корпорации International Data Corporation (IDC), называет пять главных областей, которые обходятся компаниям в миллионы долларов ежегодно. "CIO и их подразделения сосредотачиваются на пяти ключевых аспектах управления и обслуживания своих компьютеров и систем программного обеспечения: доступность, защищенность, производительность, управление проблемами и управление изменениями (availability, security, performance, problem management, and change management.)".

Доступность (Availability)

Понимание стоящих за этими цифрами скрытых затрат помогает CIO и их отделам избежать проблем, с которыми они сталкиваются. Хотя стоимость управления доступностью может быть высока, стоимость, если можно так сказать, “не управления” ею может оказаться еще выше. Очень заметный пример этого рода имел место в июне 1999 года, когда акции компании eBay упали в цене на 30% вслед за обрушением сайта компании, которое стоило онлайновому дому аукционов миллионы долларов. Компания сообщила, что выход ее сайта, на котором производились аукционы, из строя почти на 24 часа, как ожидалось, должен был уменьшить продажи во втором квартале этого (1999-го) года на 10%.

Это вовсе не изолированное событие. В праздничные каникулы по поводу Дня Благодарения 2000 года, компания Amazon.com претерпела несколько отключений электричества. Инвестиционная фирма Thomas Weisel Partners оценила, что одно 20-минутное отключение электричества приводило к потере примерно 20 000 заказов товаров и $500,000 дохода. И хотя многие компании могут не столь сильно зависеть от ИТ, как Amazon и eBay, стоимость выхода системы из строя лежит в диапазоне от $100 до $10,000 за минуту простоя.

Защищенность (Security)

Но защита от физических катастроф – не единственная статья расходов. Стоимость гарантирования безопасности системы становится все более очевидной после появления вирусов и червей Melissa, Blaster и Sobig.F. Ущерб от этих вирусов оценивается миллиардами долларов.

Но если потери от того, что не было уделено должного внимания защите, высоки, стоимость надлежащего управления защитой может казаться просто устрашающей. Команда из Лос-Аламосской лаборатории оценила, что если бы они должны были делать по одному патчу системы безопасности в месяц для своих 11 000 настольных систем, для этого потребовалось бы 87 человек на условиях полной занятости, выполняющих, в среднем, по 19 модернизаций на человека в день.

Производительность (Performance)

Совершенно ясно, что управление защищенностью уверенно стало лидером по затратам, но существенные расходы падают и на управление производительностью приложений. Рассмотрим простой вопрос управления производительностью диска. IDC приводит такую оценку: корпорации теряют в год до $50 миллиардов только потому, что не была проведена дефрагментация каждого сервера и каждой рабочей станции в сети. Возможно, управление производительностью диска не выполняется, потому что стоимость его выполнения очень высока. В IDC оценили ежегодную стоимость выполнения ручной утилиты дефрагментации диска на одной машине приблизительно в $2,080 (52 недели x 1 час в неделю x 40 долларов в час). Для сети с 25 серверами и 5 000 рабочих станций ежегодная стоимость составила бы $10 миллионов в предположении, что у компании имеются дополнительные 250 000 человеко-часов для выполнения этой работы.

Управление проблемами и изменениями (Problem management, and change management)

Еще одна область, где стоимость программного обеспечения может взлететь, подобно ракете, и намного превысить стоимость закупки – это управление изменениями. В марте 2002 года в статье в журнале Serverworld компания Gartner Group оценила стоимость перехода от Microsoft Windows 9x к Windows 2000 Professional в $2,015 и $3,191 для каждого настольного компьютера – цифры, совершенно затмевающие стоимость лицензии на одно рабочее место ($257). Но стоимость изменения не ограничивается только настольными компьютерами. Согласно проведенному в январе 2002 года компанией AMR Research обзору 109 компаний, крупное обновление системы ERP обойдется приблизительно в 18% первоначальной стоимости инсталляции. Для компаний с 500 пользователями средняя стоимость превысила $500,000 или $1,000 на каждого пользователя. Для компаний с 2 000 пользователей стоимость составила $1.2 миллиона, или $595 на пользователя. Для крупных компаний, насчитывающих более 8 400 пользователей, итоги составили $2.6 миллиона, или $300 на пользователя. Если такими были расходы два года тому назад, сколько же это стоит сегодня?

Неважно, является ли поддерживаемая система программным обеспечением базы данных, системой электронной почты, финансовым приложением или доморощенным или пакетированным приложением, поддержка ее программного обеспечения в работоспособном состоянии обходится весьма дорого.

Больше, чем деньги на стол

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

Достижение эффективности во всех пяти ключевых областях управления ИТ – огромная задача; а оценка эффективности управления – это еще большая задача. Министерство обороны (МО) США столкнулось с такой проблемой в 1980-е годы. Поскольку МО покупало все больше и больше программного обеспечения, а также заказывало разработку программного обеспечения по контрактам, оно должно было найти способ оценки качества программного обеспечения и гарантировать, что программное обеспечение поставляется вовремя и в рамках бюджета. В 1984 году МО предоставило контракт на проект Software Engineering Institute (Институт Разработки Программного обеспечения – SEI) университету Carnegie Mellon в Питтсбурге, шт. Пенсильвания. К 1987 году SEI опубликовал первую модель взросления возможностей (Capability Maturity Model –CMM) для программного обеспечения. Позже эта модель была расширена в книге Уотса Хэмфри (Watts Humphrey) “Управление софтверным процессом” (Managing the Software Process).

Фундаментальным аргументом CMM был аргумент о том, что если бы софтверная организация (разработка программного обеспечения), могла получить контроль над ключевыми процессами разработки, то высококачественное программное обеспечение производилось бы эффективно. Более того, эти ключевые процессы разработки программного обеспечения могли бы быть охарактеризованы зрелостью реализации. Процессы были разделены на пять уровней зрелости: начальный, повторяющийся, определенный, управляемый и оптимизированный (Initial, Repeatable, Defined, Managed, and Optimized). Хотя приведенные ниже определения относятся конкретно к разработке программного обеспечения, совершенно ясно, что вы можете применить их и к другим областям бизнеса.

1. Начальный (Initial). Процесс разработки программного обеспечения можно охарактеризовать как нерегламентированный и даже хаотический. Определены совсем немногие процессы, и успех зависит от индивидуальных усилий.
2. Повторяющийся (Repeatable). Приняты основные процессы управления разработкой программного обеспечения, предназначенные для отслеживания затрат, сроков и функциональных возможностей. Появляется необходимая дисциплина процесса, чтобы иметь возможность повторить предыдущие успехи проектов для аналогичных приложений.
3. Определенный (Defined). Процесс разработки программного обеспечения для действий по управлению и проектированию документирован, стандартизирован и интегрирован в стандартный софтверный процесс для организации. Все проекты используют одобренную, специально приспособленную версию стандартного софтверного процесса организации для поддержания и разработки программного обеспечения.
4. Управляемый (Managed). Собраны детальные меры процесса разработки программного обеспечения и качества продукта. И софтверный процесс, и продукты поняты количественно и управляются.
5. Оптимизированный (Optimized). Благодаря количественной обратной связи с процессом и с пилотными инновационными идеями и технологиями становится возможным непрерывное усовершенствование процесса разработки.

По мере того как организация поднимается по этим пяти уровням, улучшается предсказуемость, эффективность и контроль над процессами организации.

Операционная модель зрелости возможностей: ключевые процессы управления

Но что случается после того, как программное обеспечение передается заказчикам? С этого момента становится критичным управление стоимостью, качеством и эффективностью действия программного обеспечения. Используя уроки CMM, в корпорации Oracle развили операционную модель зрелости возможностей (Operational Capability Maturity Model), чтобы сосредоточиться на ключевых процессах эксплуатации программного обеспечения: на управлении доступностью, защищенностью, производительностью, проблемами и изменениями (management of availability, security, performance, problems, and change). Опираясь на опыт, полученный нами при управлении сотнями систем программного обеспечения, мы определили набор ключевых процессов управления, который любая организация может применить к управлению ИТ.

Управление доступностью (Availability Management). Цель управления круглосуточной доступностью (24/7) состоит в том, чтобы гарантировать непрерывную доступность приложений, баз данных, систем и аппаратных средств. Неважно, каков ваш бизнес – малый или большой глобальный. В любом случае у вас должны быть системы, которые доступны 24 часа в сутки и 7 дней в неделю.

Управление катастрофами (Disaster Management). Управление катастрофами гарантирует, что имеется процесс, который после любого бедствия обеспечит восстановление деятельности за предсказуемое время.

Управление патчами защищенности (Security Patch Management). Этот процесс должен гарантировать, что когда у поставщика появится новый патч системы безопасности, он будет применен к работающим в промышленном режиме системам не позднее известного промежутка времени.

Управление аудитом (Audit Management). Управление аудитом гарантирует, что ревизии выполняются, по крайней мере, один раз в год. Ревизии могут быть специализированы и могут придерживаться стандартов типа SAS70 – всемирно признанного стандарта аудита, разработанного американским Институтом дипломированных бухгалтеров.

Журнал Profit: об авторе Тимоти Чоу, президент корпорации Oracle по аутсорсингу, представил свои инновационные теории и решения на состоявшейся в Сан-Диего 26-29 января этого года выставке Oracle AppsWorld. Презентации Чоу и другие презентации с выставки AppsWorld доступны интерактивно на сайте oracle.com/appsworld/online.

Управление возможностями (Capacity Management). Этот процесс должен гарантировать наличие адекватных аппаратных средств и ресурсов программного обеспечения, чтобы обеспечить требуемый уровень производительности приложений.

Управление ресурсами (Resource Management). Управление ресурсами гарантирует, что есть процесс для расширения и сокращения инфраструктуры (людей и компьютеров) при увеличении и уменьшении нагрузки.

Управление модернизацией (Update Management). Этот процесс должен гарантировать, что ваше программное обеспечение обновляется, по крайней мере, один раз в год.

Оценка продуктивности (Production Assessment). Этот процесс определяет, не ухудшили ли проведенные изменения производительность, доступность или защищенность промышленно эксплуатируемых систем.

Управление эскалацией (Escalation Management). Управление эскалацией (развитием) гарантирует, что имеется процесс, охватывающий все стадии проблемы: от момента ее определения и до ее решения.

Действенное управление проблемами (Proactive Problem Management ). С его помощью вы устанавливаете процесс для получения от софтверной компании высокоприоритетных исправлений ошибок и их применения в течение определенного времени.

Конечно, создание процесса критично, но настолько же важной является зрелость процесса. Является ли этот процесс действительно нерегламентированным? В нашем случае термин “нерегламентированный” означает следующее: если ваш системный администратор и АБД находятся в офисе, то все процессы работают. Но кто знает, что произойдет, если их не будет в тот день, когда что-то произойдет? Действительно ли этот процесс является определенным (это означает, что процесс документирован)? Действительно ли он является повторяющимся, что означает, что вы используете этот процесс от 10 до 100 раз в год? Оптимизирован ли он? Используете ли вы данные, чтобы изменить и улучшить процесс? И, наконец, автоматизирован ли он? В конечном счете, любой повторяющийся процесс может быть автоматизирован – именно это является ключом к достижению более высокого качества и снижению стоимости. Посмотрите на показанный на рисунке 2 перечень "Ключевые процессы управления”, чтобы уяснить, каково сейчас ваше состояние.

Рисунок 2: Насколько зрелыми являются процессы управления на вашем предприятии? Пометьте соответствующий столбец в каждом ряду, чтобы уяснить, каково сейчас ваше состояние.

Проблема ясна. Затраты на ИТ велики и доминируют в стоимости управления имеющимися системами программного обеспечения. Затраты могут быть подразделены на гарантирующие доступность, защищенность, производительность и управление проблемами и изменениями сложных систем программного обеспечения. Сократить затраты легко, но ключом является увеличение эффективности поставки сервиса.

Основа против ситуации

Проблема, с которой сталкиваются ИТ-организации (заметим, что с той же самой проблемой сталкивается и вся корпорация в целом), состоит в том, что слишком много времени тратится на задачи, являющиеся ситуационными, и слишком мало – на задачи, являющиеся для них основными. Задача является основной, когда ее результаты непосредственно затрагивают конкурентоспособность компании. Для основных действий цель состоит в том, чтобы адаптироваться в максимально возможной степени и назначить для решения этой проблемы лучшие ресурсы. Цель для ситуационных (контекстных) задач состоит в том, чтобы выполнять их настолько эффективно и продуктивно, и настолько стандартизированным способом, насколько это возможно. Именно это является центральной темой книги Geoff Moore “Living on the Fault Line”(Джефф Мур “Жизнь на грани фола”). Он пишет: “Дифференциация контекстов – вот единственная самая большая потеря ресурсов для компаний из списка Fortune 500". Некоторые компании понимают это различие, продолжает Мур: "Для компании Chuck E. Cheese (можно предположить, что эта компания занимается производством сыра – прим. пер.) реальная пицца – это контекст, а для компании Round Table пицца – это основа". Мур утверждает, что большее ударение на основу в сравнении с контекстом проявляется как ключевое различие в распределении ресурсов для повышения биржевой стоимости акций.

Но аргументы в споре “основа против контекста” на этом не прекращаются. Менеджеры знают, что, хотя мы могли бы пробовать "сделать все это" в конце, но то, что приходится иметь дело с проблемами, возникающими при управлении контекстом, всегда влияет на наши старания сосредоточиться на основном. "Занимайтесь своим делом" – может быть, это простая старая фраза, но она не менее важна сегодня, когда мы выходим на глобальные рынки, где адаптация к стоимости является ключевым конкурентным преимуществом.

Тимоти Чоу, президент Oracle Outsourcing, является также автором книги и статьи в журнале.