Управление портфелем приложений

ИТ- Управление портфелем приложений ( APM ) — это практика, которая появилась в средних и крупных организациях информационных технологий (ИТ) с середины 1990-х годов. Управление портфелем приложений пытается использовать уроки управления финансовым портфелем для обоснования и измерения финансовых выгод каждого приложения по сравнению с затратами на обслуживание и эксплуатацию приложения.

Эволюция практики

Вероятно, самое раннее упоминание о портфеле приложений было в статье Сайруса Гибсона и Ричарда Нолана в HBR «Управление четырьмя этапами роста EDP» в 1974 году.

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

Компания Nolan, Norton & Co. стала пионером в использовании этих концепций на практике, проводя исследования в DuPont, Deere, Union Carbide, IBM, Merrill Lynch и других. В ходе этих «этапных оценок» они измеряли степень, в которой каждое приложение поддерживало или «охватывало» каждую бизнес-функцию или процесс, затраты на приложение, функциональные и технические качества. Эти меры позволили получить комплексное представление о применении ИТ в бизнесе, сильных и слабых сторонах, а также план действий по улучшению.

APM получил широкое распространение в конце 1980-х и на протяжении 1990-х годов, когда организации начали бороться с угрозой сбоя приложений, когда дата изменилась на 2000 год (угроза, которая стала известна как 2000 год или Y2K). За это время десятки тысяч ИТ-организаций по всему миру разработали исчерпывающий список своих приложений с информацией о каждом приложении.

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

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

Для поддержки подхода «сверху вниз» доступны сотни инструментов. Это неудивительно, ведь большая часть задачи состоит в сборе нужной информации; фактическое обслуживание и хранение информации может быть реализовано относительно легко. По этой причине многие организации не используют коммерческие инструменты и используют Microsoft Excel для хранения данных инвентаризации. Однако если инвентаризация становится сложной, Excel может стать громоздким в обслуживании. Автоматическое обновление данных не поддерживается решением на основе Excel. Наконец, такое решение для инвентаризации полностью отделено от потребностей понимания «снизу вверх».

Бизнес-кейс для APM

По данным Forrester Research , «в операционных бюджетах ИТ предприятия тратят две трети или более на текущие операции и обслуживание».

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

Поскольку большая часть расходов приходится на управление существующими ИТ-приложениями, прозрачность текущего реестра приложений и потребления ресурсов является основной целью управления портфелем приложений. Это позволяет компаниям: 1) выявлять и устранять частично или полностью избыточные приложения, 2) количественно оценивать состояние приложений с точки зрения стабильности, качества и удобства обслуживания, 3) количественно оценивать бизнес-ценность/влияние приложений и относительную важность каждого приложения. для бизнеса, 4) распределять ресурсы в соответствии с состоянием и важностью приложений в контексте бизнес-приоритетов.

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

Портфель

Используя идеи управления инвестиционным портфелем, специалисты APM собирают информацию о каждом приложении, используемом в бизнесе или организации, включая стоимость создания и обслуживания приложения, полученную бизнес-ценность, качество приложения и ожидаемый срок службы. Используя эту информацию, менеджер портфеля может предоставить подробные отчеты о производительности ИТ-инфраструктуры с учетом стоимости владения и полученной бизнес-ценности.

Определение приложения

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

• Прикладное программное обеспечение — исполняемый программный компонент или тесно связанный набор исполняемых программных компонентов (один или несколько), развернутых вместе, которые обеспечивают некоторые или все серии шагов, необходимых для создания, обновления, управления, расчета или отображения информации для конкретного бизнеса. цель. Чтобы быть учтенным, каждый компонент не должен быть членом другого приложения.
• Программный компонент — исполняемый набор компьютерных инструкций, содержащийся в одном контейнере развертывания таким образом, что его невозможно разбить на части. Примеры включают библиотеку динамической компоновки , веб-страницу ASP и приложение командной строки EXE . ZIP -файл может содержать более одного программного компонента, поскольку их легко разобрать (путем распаковки ZIP-архива).

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

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

Требования к определению приложения

Определение приложения имеет следующие потребности в контексте управления портфелем приложений:

• Членам бизнес-команды должно быть просто объяснять, понимать и применять.
• Это должно иметь смысл для разработки, эксплуатации и управления проектами в ИТ-группах.
• Он должен быть полезен в качестве входных данных для сложной функции, результатом которой является общая стоимость портфеля. Другими словами, существует множество факторов, влияющих на общую стоимость ИТ-портфеля. Огромное количество заявок является одним из таких факторов. Следовательно, определение приложения должно быть полезным в этом расчете.
• Это должно быть полезно для членов команды по архитектуре предприятия, которые пытаются оценить проект с точки зрения их целей по оптимизации и упрощению портфеля.
• Оно должно четко определять границы приложения, чтобы человек, работающий над измеримой деятельностью по «упрощению портфеля», не мог просто переопределить границы двух существующих приложений таким образом, чтобы называть их одним приложением.

Многие организации будут пересматривать определение приложения в контексте своей практики управления и руководства ИТ-портфелем . По этой причине данное определение следует рассматривать как начало работы.

Примеры

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

Включения

Согласно этому определению, приложениями являются:

• Конечная точка веб-службы , представляющая три веб-службы: InvoiceCreate, InvoiceSearch и InvoiceDetailGet.
• Сервисно-ориентированное бизнес-приложение ( SOBA ), которое представляет пользовательский интерфейс для создания счетов, а также вызывает службу InvoiceCreate . (обратите внимание, что сама служба представляет собой другое приложение).
• Мобильное приложение , которое публикуется в магазине корпоративных приложений и, таким образом, развертывается на портативных устройствах, принадлежащих или управляемых сотрудниками, обеспечивая аутентифицированный доступ к данным и службам.
• Устаревшая система, состоящая из мощного клиента, серверного среднего уровня и базы данных, которые тесно связаны между собой. (например, изменения в одном с большой вероятностью вызовут изменения в другом).
• Система публикации веб-сайта, которая извлекает данные из базы данных и публикует их в формате HTML в качестве дочернего сайта по общедоступному URL-адресу.
• База данных, которая представляет данные в книгу Microsoft Excel , которая запрашивает информацию для макета и вычислений. Это интересно тем, что база данных сама по себе является приложением, если только она уже не включена в другое приложение (например, в устаревшую систему).
• Электронная таблица Excel , содержащая последовательный набор повторно используемых макросов, которые приносят пользу бизнесу. Сама электронная таблица представляет собой контейнер развертывания приложения (например, файл TAR или CAB ).
• Набор веб-страниц ASP или PHP , которые работают вместе, обеспечивая функциональность и логику веб-приложения. Вполне возможно, что подсайт будет квалифицироваться как отдельное приложение в соответствии с этим определением, если связь будет слабой.
• Конечная точка веб-сервиса, созданная для межмашинного взаимодействия (а не для взаимодействия между людьми), но которую можно рационально понимать как представляющую один или несколько полезных шагов в бизнес-процессе.

Исключения

Следующие приложения не являются приложениями:

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

Композиты

Ниже приведено множество приложений:

• Составное SOA- приложение, состоящее из набора повторно используемых сервисов и пользовательского интерфейса, который использует эти сервисы. Здесь есть как минимум два приложения (пользовательский интерфейс и один или несколько сервисных компонентов). Каждая услуга не считается приложением.
• Устаревшее клиент-серверное приложение, записывающее данные в базу данных для хранения данных, и электронная таблица Excel, которая использует макросы для чтения данных из базы данных и представления отчета. В этом примере есть ДВА приложения. База данных явно принадлежит устаревшему приложению, поскольку она была разработана вместе с ним, доставлена ​​вместе с ним и тесно с ним связана. Это верно, даже если устаревшая система использует те же хранимые процедуры, что и электронная таблица Excel.

Методы и меры оценки заявок

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

Возврат инвестиций (ROI)

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

Экономическая добавленная стоимость (EVA)

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

Формула = Чистая операционная прибыль после налогов (NOPAT) - (Капитал * Стоимость капитала)

Общая стоимость владения (TCO)

Общая стоимость владения — это способ подсчитать, сколько будет стоить приложение в течение определенного периода времени. В модели совокупной стоимости владения затраты на оборудование, программное обеспечение и рабочую силу фиксируются и распределяются по различным этапам жизненного цикла приложения. Подробная модель совокупной стоимости владения помогает руководству понять истинную стоимость приложения при попытке измерить стоимость сборки, запуска/поддержки, а также косвенные затраты. Многие крупные консалтинговые фирмы определили стратегии построения полной модели совокупной стоимости владения.

Общий экономический эффект (TEI)

TEI был разработан компанией Forrester Research Inc. Forrester утверждает, что TEI систематически рассматривает потенциальные последствия инвестиций в технологии по четырем направлениям: стоимость — влияние на ИТ; выгоды — влияние на бизнес; гибкость — будущие возможности, создаваемые инвестициями; риск — неопределенность.

Ценность ИТ для бизнеса (ITBV)

Программа ITBV была разработана корпорацией Intel в 2002 году. Программа использует набор финансовых показателей стоимости бизнеса, которые называются шкалами стоимости бизнеса (индикаторами). Это многоплановая программа, включающая бизнес-компонент, и ее относительно легко реализовать.

Прикладная информационная экономика (ПИИ)

AIE — это метод анализа решений, разработанный Hubbard Decision Research. AIE утверждает, что это «первый по-настоящему научный и теоретически обоснованный метод», основанный на нескольких методах теории принятия решений и анализа рисков, включая использование методов Монте-Карло. AIE используется нечасто из-за его сложности.