Оригинал статьи: http://www.ibm.com/developerworks/rational/library/edge/09/mar09/oneill/index.html

Colin O'Neill, Ведущий консультант, OCS Process Works

Эта статья иллюстрирует, каким образом, не испытывая серьезных затруднений, можно оценить чистый возврат инвестиций, который может иметь место в результате усилий, предпринятых при внедрении улучшений в IT процессе.
От журнала Rational Edge: Среди многочисленных изменений в софтверной индустрии в последние 40 лет, оценка на применение информационных технологий (IT) с точки зрения эффективности возврата инвестиций имеет довольно драматичный оттенок. В течение десятилетий IT расценивались, как область, необходимая с точки зрения вложения денег с целью развития бизнеса. Сегодня те подразделения, которые приносят прямой доход в организации, относятся к разработке программного обеспечения, как к важнейшей части своей инфраструктуры и мощному способу получения конкурентных преимуществ. И действительно, большинство компаний, которые не позиционируют сферу информационных технологий, как ключевую часть своей бизнес стратегии, направленной на снижение цен на товары и услуги и повышение их качества, однозначно имеют тенденцию к потере своего рынка. Простое правильное позиционирование сферы IT и соответствующих процессов представляются на сегодняшний день жизненно необходимыми для удержания корпораций в бизнесе на должном уровне.

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

Улучшения в IT процессе могут быть наглядно продемонстрированы с помощью ROI. В данной статье приводится подтверждение этому и описывается в примерах, как это может быть сделано.

Расчет снижения себестоимости

Некоторые финансовые эксперты заявляют, что существует разница между понятиями снижения себестоимости и сокращения затрат. Но позвольте в нашей дискуссии мне считать, что они представляют собой одно и то же, и вот почему: ключ к повышению производительности заключается в снижении количества времени, которое требуется исполнителю в организации для того, чтобы сделать "нечто" полезное. Улучшение процесса содействует снижению себестоимости производства в случае, если процесс четко выстроен и хорошо документирован. Тогда применение широко известных "лучших практик" (Best Practices) приводит к снижению количества времени, которое необходимо исполнителю для достижения той или иной цели или выполнения конкретной задачи. Таким образом, если взять затрачиваемое количество времени X перед тем, как процесс будет улучшен, и взять количество времени Y после этого, то можно рассчитать разность X минус Y для получения данных об экономии, являющейся следствием повышения производительности.

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

Этапы улучшения IT процесса

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

В этой статье второй этап поделен на три шага, которые требуется выполнить:

• Шаг 1: Идентифицировать участки, где улучшение процесса может быть эффективно измерено и рассчитано
• Шаг 2: Разработать логически вытекающие, внушающие доверие формулы для вычисления себестоимости по каждой группе улучшений в процессе
• Шаг 3: Определить нижний порог ROI , на основании которого оценивается необходимость проведения работы по улучшению процесса

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

Шаг 1: Идентифицировать участки, где улучшение процесса может быть эффективно измерено и рассчитано

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

Метод вычисления ROI, описанный здесь, полностью поддерживает системный подход IBM® Measured Capability Improvement Framework (MCIF), направленный на итеративное развитие организаций, в деятельности которых присутствуют IT направления. Используя MCIF, компании могут внедрить одну или более практик за раз (практика -- это документированный подход для решения одной или нескольких общеизвестных проблем) и идентифицировать упомянутую ранее базовую линию. Практики сами по себе созданы для того, чтобы оказывать положительное влияние на достижение одной или нескольких бизнес целей, таких как время выхода на рынок, повышение качества, внедрение новаторских принципов и др., и могут быть эффективно измерены.

Типы IT процессов

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

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

IT процессы непроектного типа обычно документируют и информируют специалистов о более долгосрочных аспектах обслуживания уже поставленного программного обеспечения, особенно в таких областях, как техническая поддержка и сопровождение. К ним относятся (перечислим лишь несколько):

• Работа службы технической поддержки (Service Desk)
• Управление инцидентами (Incident Management)
• Управление проблемами (Problem Management)
• Управление изменениями (Change Management)
• Управление конфигурациями (Configuration Management)
• Управление релизами (Release Management)
• Управление доступностью (Availability Management)
• Управление мощностями (Capacity Management)
• Управление уровнем услуг (Service Level Management)

Общие перспективы снижения затрат

Некоторые хорошие техники для снижения затрат (как для процессов проектного типа, так и для непроектного), используемые в типичной IT организации:

• Повышение качества продукта, благодаря применению стандартов, сформулированных в виде лучших практик (Best Practice) -- усиленный контроль над созданием требований, проекта архитектуры и кода; более эффективное тестирование и т.д.
• Более эффективное руководство и управление портфелем проектов, отслеживание времени, управление проектами, управление стоимостью и задействованием ресурсов
• Максимально раннее подключение ключевых лиц, заинтересованных в положительном конечном результате проекта, чтобы иметь от них оперативную обратную связь
• Повышение качества составления проектных расписаний и прогнозирования, как части управления мощностями, так и запросами
• Улучшение качества технической поддержки и предоставления услуг конечным пользователям
• Более эффективное управление вендорами (Vendor Management)
• Ускоренный ввод нового персонала
• Уменьшение затрат времени на проведение совещаний
• Снижение затрат времени на перепроектирование и перекодирование
• Снижение затрат времени на диспуты внутри персонала организации и с внешними вендорами
• Снижение затрат времени на поиск шаблонов и потенциальных решений
• Уменьшение расхождений между различными командами, позициями, культурами и языками
• Уменьшение необходимости в обучении методологии и повышению навыков для внутреннего персонала

Увеличение качества программного обеспечения обычно тяжело измерить. Но при этом можно проследить, насколько сильно возросло качество развернутой информационной системы в условиях улучшенного процесса и как это отразилось, например, в таких факторах, как "снижение числа обращений в техническую службу помощи (Help Desk), благодаря уменьшению числа дефектов" или "насколько увеличилось число продаж, благодаря более понятному пользовательскому интерфейсу".

Пример из реального мира

Недавно один наш клиент сокрушался, что перед тем, как проект стартовал, его участники потратили почти месяц на выполнение работ, которые не пришлось бы делать в случае формализованного процесса, базирующегося на лучших практиках, таких как:

• Определение, какие роли должны выполняться специалистами и какие обязанности должны быть включены в эти роли
• Определение подходов и техник при выполнении проектов подобного типа
• Идентификация шаблонов, документов и примеров из других проектов, которые могли бы принести пользу для данного проекта (включая рутинное перекапывание многочисленных сетевых дисков, часто с неясным предназначением, ради поиска нужных файлов, а также идентификацию версии, которую требуется использовать)
• Очерчивание иерархической структуры задач (Work Breakdown Structure, WBS), как основы для составления проектного расписания
• Доведение до участников проекта, что именно они должны сделать и когда это надо сделать

Имея такой сценарий на руках, предположим, что для старта проекта из 10 человек требуется 3 недели подготовки к нему. Также предположим, что в эти три недели каждый из участников потратил на выполнение работ, перечисленных в списке выше, в среднем 20% времени. При полной ставке $65 в час для большинства IT¹ специалистов и 40 оплачиваемых рабочих часов в неделю в течение указанных трех недель, сэкономленный остаток при наличии унифицированного, документированного и отлаженного процесса мог бы составить $15,600 (10 человек x 3 недели x 40 часов/в неделю x 20% сэкономленного времени x $65/в час). Затем полученный результат следует умножить на число проектов, стартовавших в течение одного года (пусть это будет десять проектов для IT организации среднего размера) и получается, что экономия в $156,000 достигается уже только на этапе проведения подготовительных работ в проектах. Это своеобразная проблема, которая вполне типична для IT организаций. Так что можно свободно готовиться говорить о том, сколько придется платить дополнительно, если отсутствует то или иное улучшение в процессе.

Процесс в роли организатора

Простая организация работы IT подразделения уже способна принести значительные дивиденды. Есть причины поддерживать такой порядок непрерывно, потому что это помогает профессиональным специалистам добиваться реализации поставленных перед ними целей и делает их жизнь менее стрессовой. Аналогичным образом, организация IT процесса (или любого другого рассматриваемого бизнес процесса) позволяет специалистам более эффективно реализовывать свое предназначение и одновременно сохранять небольшое чувство юмора. Кроме того, порядок отражается в повышении производительности, потому что люди в целом обычно более созидательны при условиях меньшего стресса.

Шаг 2: Разработать логически вытекающие, внушающие доверие формулы для вычисления экономии

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

Из списка возможных путей снижения себестоимости на шаге 1, давайте отберем четыре направления:

• Ускоренный ввод нового персонала
• Уменьшение затрат времени на проведение совещаний
• Более эффективное руководство и управление портфелем проектов
• Улучшение качества технической поддержки и предоставления услуг

В примерах, описанных далее, сделано допущение, что деятельность по улучшению процесса имела место в 2009 году, и она привела к снижению затрат в последующие годы (с 2010 по 2012). Все затраты на персонал базируются на средней оценке полной ставки среди служащих IT сферы в США в 2009 г. (в долларах США), которая традиционно соответствует $65 в час¹ при 40-часовой рабочей неделей (всего 48 недель в год).

Пример 1: Ввод нового персонала

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

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

Таблица 1: Экономия в результате более эффективного ввода нового персонала

Пример 2: Уменьшение затрат времени на проведение совещаний

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

Таблица 2: Экономия, благодаря рационализации подходов по проведению совещаний

Пример 3: Более эффективное руководство и управление портфелем проектов

Давайте теперь перейдем от оценки экономии на уровне отдельного специалиста к оценке экономии на уровне организации в целом.

Таблица 3: Экономия при  более эффективном руководстве в ITсфере

Пример 4: Улучшение качества технической поддержки и предоставления услуг

Здесь существуют два направления, которые могут привести к уменьшению затрат:

• Снижение количества времени, требуемого специалистам проектной команды для формирования отчетов об инцидентах и проблемах, выполнения звонков в службу технической поддержки и ожидания их разрешения

• Сокращение числа специалистов центра технической поддержки, необходимых для оказания вышеперечисленных услуг

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

Таблица 4: Экономия средств с помощью улучшения качества технической поддержки и предоставления услуг

Направление 1: Экономия на уровне отдельного специалиста команды

Направление 2: Экономия на уровне персонала технической поддержки

Шаг 3: Определение стоимости затраченных усилий и вычисление ROI

Предположим, что четыре направления, изложенные выше, являются единственными, на основании которых можно судить об экономической эффективности. Несмотря на то, что приведенные примеры по отдельности довольно просты, вместе они обеспечивают "железное" доказательство тому, что реальное улучшение процесса приносит выгоду с экономической точки зрения. Разумеется, следует отметить, что где-то эта экономия более очевидна, и некоторые направления позволяют сохранить больше денег, чем другие. Чем больше требуется подпитывать проект, направленный на улучшение процесса разработки, тем больше его граней необходимо идентифицировать и оценивать при экономическом обосновании его преимуществ.

На этом шаге, во-первых, необходимо определить стоимость усилий по улучшению процесса. В примере, приведенном ниже, в 2009 году ожидаются затраты в размере $1,112,300 на улучшение различных элементов всего процесса, в частности на:

• Проведение консалтинговой экспертизы Инженером процесса
• Уделение некоторого времени этому со стороны внутреннего персонала организации
• Затраты ресурсов на проведение теоретического обучения
• Затраты на обучение практическим навыкам и наставничество в рамках пилотного проекта
• Затраты на переезды и т.п.
• Затраты на внедрение средств автоматизации

Стоимость улучшения процесса

Таблица 5 содержит пример расчета затрат на улучшение всего процесса.

Таблица 5: Оценка стоимости улучшения процесса

Определите конечную выгоду

Таблица 6 суммирует, как стоимость улучшения процесса (см. Таблицу 5 выше), так и величину экономии (см. Шаг 2 выше) для вычисления итоговой окончательной выгоды. Если можно показать экономию средств в 2009 (как раз в этот год и шла работа по улучшению процесса), то можно определить экономию по каждому из направлений, перечисленных на Шаге 2.

Композиция хорошего процесса

При исследовании возможностей демонстрации ROI для улучшения процесса давайте определим, что именно означает характеристика "хороший" или "улучшенный" процесс. В соответствии со стандартом Software Process Engineering Metamodel (SPEM) организации Object Management Group (OMG) хороший процесс должен быть четко выстроен в двух основных сферах: контент (content) и процессы (process).

Контент дает описание в терминах фундаментальных элементов, которые можно поделить на четыре категории: роли (roles), задачи (tasks), рабочие продукты (work products) и руководства (guidance's). Определение ролей помогает специалистам понять свои обязанности и навыки, требуемые для выполнения назначенных им задач. Задачи, выстроенные в виде цепочек шагов, для каждого из которых определены специфические результаты и цели, выполняются ролями, и с ними также связаны рабочие продукты (иногда называемые артефактами), которые являются входными данными для этих задач. При выполнении задачи входные данные преобразуются в выходные (это аналогичные рабочие продукты), но с некоторой добавленной пользой по отношению ко всему процессу в целом. Рабочие продукты являются промежуточными или окончательными результатами процесса, каждый из которых делает некоторый вклад в разработку поставляемого продукта или сервиса. Руководства создаются для разнообразной поддержки ролей, задач и рабочих продуктов. Они могут включать политики, шаблоны, примеры, описание стандартов, контрольные опросники (checklists), концепции (concepts), белые страницы (white papers), материалы поддержки и т.д. Процессы представляют собой связывание вместе элементов контента для выполнения сквозной последовательности действий во множестве фаз разработки для достижения необходимого результата, обычно создания программного приложения, дистрибутива или конфигурации, обновления существующей системы и выполнения полезной работы. В рамках конкретной IT организации могут существовать несколько "процессов поставки" ("delivery processes"); по одному на каждый основной тип проектов. С каждым процессом поставки связывается только один контент (в терминах ролей, задач, рабочих продуктов и руководств), который также соответствует некоторому типу проектов.

Внедренные инструменты

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

IBM Rational® Method Composer является мощной и гибко настраиваемой платформой для управления процессами, которая позволяет быстро разработать, сконфигурировать и опубликовать полноценное описание IT процесса в HTML формате в масштабе всей организации. В него входит богатая и расширяемая библиотека процессных активов, включающая описание лучших промышленных практик из области разработки программ и информационных систем, жизненного цикла разработки и организации управления IT. Поскольку Rational Method Composer предоставляет общую структуру и принципы построения для всего контента процесса в масштабе всей IT организации. В нем фиксируется надежный процесс, предназначенный для использования каждой командой, а также полное описание рабочих жизненных циклов от начала до конца (т.е. процессов поставки); если короче, то это помогает членам проектной команды понять, что именно делать, когда и как это делать.

Rational Method Composer построен на функционале Eclipse, платформе разработки программного обеспечения де факто, которая использует концепцию "плагинов" ("plug-ins") для расширения возможностей инструментария. Rational Method Composer совмести со стандартом OMG SPEM, включающим понятие строительных блоков для описания процесса, т.н. шаблонов возможностей (capability patterns), и представляют описания лучших практик, практических приемов, технологий и стилей разработки для соответствующих дисциплин. Эти многократно используемые строительные блоки являются частью инструментария для быстрой сборки процессов поставки на основе специфических проектных потребностей.

Результатом работы в Rational Method Composer является статический HTML Web сайт с множеством гиперссылок, организованных по Вашему желанию и полностью документирующих Ваш IT процесс. Опубликованный Web сайт может быть развернут на любом Web или файловом сервере, таким образом, позволяя каждому сотруднику организации с браузером и доступом в локальную сеть получать в любое время описание актуальных процессов поставки, шаблоны, описания стандартов, политик и др. без опасений столкнуться с устаревшими материалами. Инструмент также дает возможность экспортировать данные в Microsoft Project, что служит отличной отправной точкой для менеджеров проектов при начале проекта того или иного типа.

Rational Method Composer содействует быстрому старту проекта, позволяя инженерам процессов и менеджерам проектов быстро собирать необходимые элементы, сшивать их в единое целое и составлять процессы для выполнения специфических проектов. Это колоссальная возможность для разработки прототипов процессов, публикации их в организации и получения оперативной обратной связи об их работоспособности.

Компания IBM, постоянно принимающая активное участие в работе сообщества с открытым исходным кодом (open source), является первичным спонсором для проекта Eclipse Process Framework. Инструмент Eclipse Process Framework Composer (EPFC) является ядром для Rational Method Composer. Вдобавок к контенту, подобному IBM Rational Unified Process® (RUP®) и практикам от IBM, Rational Method Composer приносит дополнительные возможности по отношению к EPFC, такие как способность публикации процесса не только в виде Web сайта, но и в форматах PDF и Microsoft Word. Rational Method Composer уже включает пакеты для создания стандартного описания RUP, которое является большой, основанной на реальных практиках библиотекой, и набором дополнительных плагинов. В список плагинов EPFC входят OpenUP (гибкая производная Rational Unified Process), практики EPF, Scrum, Extreme Programming (XP), Dynamic Systems Development Method (DSDM), и Agile Business Rule Development (ABRD).

Rational Method Composer и EPFC полностью поддерживают деятельность по улучшению процесса, и оба инструмента являются доступными для получения и организации эффективной работы.

Заключение

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

• Определите направления улучшения процесса
• Определите надежные формулы для вычисления экономической отдачи
• Рассчитайте стоимость усилий и вычислите RO

Существует промышленный стандарт в области практик (SPEM), который позволяет выстроить хороший процесс, при этом, инструмент Rational Method Composer базируется на SPEM. И Rational Method Composer, и EPFC дают возможность организациям мощные и легко используемые возможности по документированию, управлению и публикации IT процессов. В общем и целом эти инструменты позволяют осуществить хороший стартовый рывок для IT организаций, которым требуется документирование процессов, в рамках которых проводится работа по снижению затрат.

Замечания

1. В соответствии с данными Центра США по статистике в области трудовой занятости (United States Bureau of Labor Statistics) средний заработок служащего IT составил $39.85/в час в 2007 г. Почасовая ставка с полной занятостью обычно выше в 1.5 и 2.5 раза, чем указанная выше. Поэтому часовая ставка $40 умножается на усредненный коэффициент 1.65 (который является стандартным коэффициентом при таких расчетах) и получается $65 в час, что обычно и используется при расчетах ROI.