Вычисление ROI при внедрении улучшений в процессе

Оригинал статьи: 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 в час для большинства IT1 специалистов и 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 в час1 при 40-часовой рабочей неделей (всего 48 недель в год).

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

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

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

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

Количество

 

 

Формула и расчеты

 

 

Комментарии и допущения

 

 

 

 

 

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

 

 

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

 

 

 

 

 

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

 

 

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

 

 

$93,600

 

 

2010 = (300 служащих x 10% текучести x 3 недели x 40 часов/в неделю x $65/в час x 40% сэкономленного времени)

 

 

Время ввода снижено на 40% в первый год

 

 

$117,000

 

 

2011 = (300 служащих x 10% текучести x 3 недели x 40 часов/в неделю x $65/в час x 50% сэкономленного времени)

 

 

Время ввода снижено на 50% на второй год

 

 

$140,400

 

 

2012 = (300 служащих x 10% текучести x 3 недели x 40 часов/в неделю x $65/в час x 60% сэкономленного времени)

 

 

Время набора снижено на 60% на третий год и далее считаем данный уровень пороговым

 

 

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

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

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

Количество

 

 

Формула и расчеты

 

 

Комментарии и допущения

 

 

 

 

 

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

 

 

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

 

 

 

 

 

Вычисляется, как процент времени, сэкономленного на каждом совещании каждым специалистом IT организации среднего размера в 300 человек (это относится к каждому специалисту независимо от его роли), в течение года

 

 

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

 

 

$561,600

 

 

2010 = (300 служащих x 6 часов/в неделю x 48 недель x $65/в час x 10% сэкономленного времени)

 

 

 

 

 

$561,600

 

 

2011 = (300 служащих x 6 часов/в неделю x 48 недель x $65/часов x 10% сэкономленного времени)

 

 

 

 

 

$561,600

 

 

2012 = (300 служащих x 6 часов/в неделю x 48 недель x $65/часов x 10% сэкономленного времени)

 

 

 

 

 

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

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

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

Количество

 

 

Формула и расчеты

 

 

Комментарии и допущения

 

 

 

 

 

Цель: Уменьшить число невыгодных проектов и некорректно назначенных ресурсов.

 

 

Здесь снижается количество времени на проекты, к которым изначально нельзя было приступать, потому что:

 

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

 

 

 

 

Вычисляется, как количество чистых долларов, сэкономленных за год в IT организации среднего размера из 300 человек с ежегодным бюджетом $50 млн.

 

 

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

 

 

$2,500,000

 

 

2010 = ($50,000,000 x 5%)

 

 

 

 

 

$2,500,000

 

 

2011 = ($50,000,000 x 5%)

 

 

 

 

 

$2,500,000

 

 

2012 = ($50,000,000 x 5%)

 

 

 

 

 

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

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

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

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

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

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

Количество

 

 

Формула и расчеты

 

 

Комментарии и допущения

 

 

 

 

 

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

 

 

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

 

 

 

 

 

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

 

 

Сделаем допущение, что снижается 20% времени, затрачиваемого каждым специалистом IT организации при регистрации и сопровождении запросов в области технической поддержки. Допустим, что в год на каждого специалиста приходится два запроса по технической поддержке, каждый из которых в среднем требует одного часа на обработку и сопровождение вплоть до полного закрытия.

 

 

$7,800

 

 

2010 = (300 служащих x 1 час/на запрос x 2 запроса/в год x $65/в час x 20% сэкономленного времени)

 

 

 

 

 

$7,800

 

 

2011 = (300 служащих x 1 час/на запрос x 2 запроса/в год x $65/в час x 20% сэкономленного времени)

 

 

 

 

 

$7,800

 

 

2012 = (300 служащих x 1 час/на запрос x 2 запроса/в год x $65/в час x 20% сэкономленного времени)

 

 

 

 

 

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

Количество

 

 

Формула и расчеты

 

 

Комментарии и допущения

 

 

 

 

 

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

 

 

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

 

 

 

 

 

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

 

 

Считаем, что служба технической поддержки работает в режиме 24x7 и состоит из шести человек. Также полагаем, что имеет место 20% снижение затрат времени, начиная от начальной регистрации заявки и кончая полным завершением работы по ней.

 

 

$149,760

 

 

2010 = (6 служащих x 40 часов/в неделю x 48 недель/в год x $65/в час x 20% сэкономленного времени)

 

 

 

 

 

$149,760

 

 

2011 = (6 служащих x 40 часов/в неделю x 48 недель/в год x $65/в час x 20% сэкономленного времени)

 

 

 

 

 

$149,760

 

 

2012 = (6 служащих x 40 часов/в неделю x 48 недель/в год x $65/в час x 20% сэкономленного времени)

 

 

 

 

 

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

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

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

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

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

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

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

Стоимость

 

 

Статья

 

 

Формула и расчеты

 

 

Комментарии и допущения

 

 

$230,400

 

 

Консалтинг

 

 

2009 = 2 консультанта x 40 часов/в неделю x 24 недели x 75% времени x $160/в час

 

 

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

 

 

$374,400

 

 

Задействование внутреннего персонала

 

 

2009 = 300 служащих x 10% персонала x 40 часов/в неделю x 24 недель x 20% времени x $65/в час

 

 

10% персонала должны отводить в течение шести месяцев 20% своего времени на проектирование, документирование и контроль результатов, включая участие во встречах и совещаниях.

 

 

$100,000

 

 

Обучение теории

 

 

2009 = 2 преподавателя x 500 часов/на преподавателя x $100/в час

 

 

Двум преподавателям понадобится подготовить и провести обучение в течение трех месяцев еще до промышленного запуска процесса.

 

 

$300,000

 

 

Наставничество/ обучение практическим навыкам

 

 

2009 = 2 наставника x 1,000 часов/на наставника x $150/в час

 

 

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

 

 

$67,500

 

 

Переезды

 

 

2009 = 300 служащих x 10% персонала x 1.5 командировки x $1,500 на командировку

 

 

Среди 10% персонала на каждого в среднем приходится 1.5 командировки, стоимость затрат на командировку для одного человека составляет $1,500.

 

 

$74,880
каждый год

 

 

Сопровождение процесса

 

 

Каждый год = 300 служащих x 10% персонала x 40 часов/в неделю x 48 недель x 2% времени x $65/в час
2010 = $74,880
2011 = $74,880
2012 = $74,880

 

 

10% персонала должны уделять 2% своего времени на операции контроля, коррекции и улучшения материалов процесса, включая участие в обсуждениях и совещаниях.

 

 

$40,000 каждый год

 

 

Инструментарий

 

 

2009 = $40,000
2010 = $40,000
2011 = $40,000
2012 = $40,000

 

 

Средний проект по улучшению процесса расходует $40,000 в год на приобретение лицензий.

 

 

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

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

Направление

 

 

2009

 

 

2010

 

 

2011

 

 

2012

 

 

Итого

 

 

Улучшение процесса

 

 

(1,112,300)

 

 

(114,880)

 

 

(114,880)

 

 

(114,880)

 

 

(1,456,940)

 

 

Ускоренный ввод нового персонала

 

 

 

 

 

93,600

 

 

117,000

 

 

140,400

 

 

351,000

 

 

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

 

 

 

 

 

561,600

 

 

561,600

 

 

561,600

 

 

1,684,800

 

 

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

 

 

 

 

 

2,500,000

 

 

2,500,000

 

 

2,500,000

 

 

7,500,000

 

 

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

 

 

 

 

 

7,800

 

 

7,800

 

 

7,800

 

 

23,400

 

 

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

 

 

 

 

 

149,760

 

 

149,760

 

 

149,760

 

 

449,280

 

 

Итоговая выгода

 

 

 

 

 

 

 

 

 

 

 

 

 

 

$8,551,540

 

 

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

При исследовании возможностей демонстрации 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.

 

© 2008-2016 Финэкософт.

 

Oracle Silver Partner
+7 (495) 664 4727
Учебный центр
Центр обучения и сертификации в области информационных технологий (IT).

Широкий выбор курсов и программ обучения. Подробности здесь.

Отправить письмо
Обратная связь

 

Для Ваших вопросов и отзывов