Модели и инструменты управления портфелем приложений реферат

Обновлено: 04.07.2024

ЭТО Управление портфелем приложений (APM) - практика, появившаяся в средних и крупных информационные технологии (ИТ) организации с середины 1990-х годов. [1] Application Portfolio Management пытается использовать уроки финансовый портфель руководство для обоснования и измерения финансовой выгоды каждого приложения по сравнению с затратами на обслуживание и эксплуатацию приложения.

Содержание

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

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

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

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

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

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

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

портфолио

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

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

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

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

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

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

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

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

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

Примеры

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

Включения

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

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

Исключения

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

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

Композиты

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Существуют различные способы оценки портфеля и различные классификации прикладных систем предприятия. Одной из возможных моделей оценки портфеля прикладных систем является оценка их по двум критериям – ценность с точки зрения бизнеса и техническое состояние, что проиллюстрировано на рис. 6.3 [4.19].

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

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

системам грозит вывод из эксплуатации (замена) или консолидация;
системы, требующие переоценки или перепозиционирования;
системы, требующие обновления;
системы, требующие сопровождения и развития.

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

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

Ниже даны краткие характеристики каждой категории систем в соответствии с этой классификацией:

Этот же способ оценки назван Матрицей оценки состояния прикладных информационных систем (Health Grid) [4.14]. Графическое расположение систем на матрице, кроме двух параметров – ценность с точки зрения бизнеса и техническое состояние, – может нести в себе еще и дополнительную информацию. Во-первых, каждой прикладной системе соответствует круг, диаметр которого пропорционален общей стоимости информационной системы, с учетом стоимости приобретения, эксплуатации и сопровождения (стоимости обновлений). Во-вторых, круги окрашиваются в один из пяти цветов, характеризующих реальную важность системы, а не просто потенциальную ценность для бизнеса (например, система в данный момент может считаться малоценной для бизнеса, но достаточно важной, поскольку ценность ее может быть повышена в будущем за счет обновления и обеспечения доступа к накопленным данным через Интернет).

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

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

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

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

Название системы.
Описание системы.
Список технологических компонентов. Это важно, поскольку они могут использоваться независимо для построения других решений. При этом основные компоненты должны быть отдельно описаны, включая их функции и техническое состояние.
Область применения с точки зрения бизнеса, т.е. функциональные возможности (например, CRM, финансы, управление кадрами, каналы продаж через Интернет и пр.).
"Владелец" системы со стороны бизнеса.
Оценка пользы прикладной системы для бизнеса.
Ответственный со стороны ИТ-подразделения.
Оценка технического состояния.
Оценка возможностей по обеспечению новых потребностей бизнеса.
Дата обновления этой информации.

Для оценки портфеля прикладных систем может быть также использована модель, предложенная Gartner [4.20].

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

Интересно то, что совершенно разные авторитетные источники – Gartner, META Group, а также Уэйл и Броадбент в своей книге "Использование возможностей инфраструктуры. Как лидеры рынка получают преимущества от информационных технологий" [4.20], [4.19], [4.14] – дружно выделяют три категории прикладных систем, правда, используя для обозначения этих категорий несколько разные определения. Однако критерии отнесения прикладных систем к той или иной категории при этом полностью совпадают.

4. АРХИТЕКТУРА ПРИЛОЖЕНИЙ

4.1. Основные элементы архитектуры приложений
В архитектуре приложений выделяют две основные области (рис. 11) [4]:

формирование и управление портфелем прикладных систем предприятия;
разработка прикладных систем.

Рис. 11. Области архитектуры приложений

Портфель прикладных систем предприятия необходим для обеспечения бизнес-процессов набором прикладных систем. Он определяет функциональность каждого приложения, а также то, за счет чего она будет достигаться [10]:
- за счет разработки новой системы;
- за счет покупки готовых систем;
- за счет аренды приложения;
- за счет использования уже имеющихся приложений.
Приложения, задаваемые портфелем прикладных систем предприятия, описывают функции организации, обмен информационных потоков на предприятии, каналы взаимодействия пользователей с приложениями [23]: web-браузеры, графический интерфейс "толстого" клиента, мобильные устройства и т.д.
Портфель прикладных систем обеспечивает целостный взгляд на функциональные компоненты информационных систем, которые обеспечивают потребности бизнес-архитектуры и архитектуры информации и поддерживаются технологической архитектурой.
Область разработки прикладных систем описывает технологии, которые используются для построения систем. Она касается также создания интерфейсов, выбора шаблонов и т.д. Эта область отвечает за организацию процесса разработки, т.е. за выбор технологий для построения приложений и способов их применения [41].
Область разработки прикладных систем ответственна за соблюдение единых подходов к разработке, что влияет на уменьшение стоимости создания прикладных систем [2].
Важно отметить ту часть разработки прикладных систем, которая затрагивает шаблоны проектирования, так как шаблоны находятся на стыке между обеспечением функциональных возможностей и технологиями. Шаблоны по сути являются руководствами по построению систем.
Изучая архитектуру приложений, под ней понимают портфель прикладных систем [31].

4.2. Модели и инструменты управления портфелем приложений
Оценка портфеля является начальным моментом в деле определения проблемных областей и возможностей для улучшения бизнеса и принятия решения об обновлении прикладных систем [2].
В результате оценки прикладных систем их разделяют на 4 группы [25]:

системы, которые могут выйти из эксплуатации;
системы, которые требуется переоценить;
системы, которые требуется обновить;
системы, которые возможно развить.

Характеристики оценки технического состояния [15]:
– точность данных;
– корректность данных;
– архитектура;
– структура программного кода;
– быстрота отклика;
– время простоя;
– уровень технического сопровождения;
– возможность получения отчетов и т.д.
Информация по имеющимся в организации прикладным системам должна включать [28]:

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

Для оценки портфеля прикладных систем может быть также использована модель, предложенная Gartner [2, 10].
Выделяют 3 класса приложений согласно следующим категориям [11]:

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

На основании этих данных делают финансовую оценку вложений в ИТ на предприятии [28].
Базовые транзакционные (или вспомогательные, или обслуживающие) приложения играют важную роль с точки зрения обеспечения деятельности организации. Они должны иметь низкую стоимость, надежность, стоимость одной транзакции такого приложения должна быть минимальной. Этих приложений в портфеле информационных систем предприятия обычно большинство.
Информационные (дающие преимущества) – это те приложения, которые улучшают деятельность организации. Они обеспечивают информацию для учета, управления, контроля, получения отчетов, анализа, совместной работы.
Инновационные (стратегические или "пограничные") приложения носят принципиально новый характер влияния на функционирование организаций. Эти приложения создают новые конкурентные преимущества на рынке.
В совокупности с тремя типами прикладных систем следует рассматривать еще одну категорию инвестиций в информационные технологии, так называемую технологическую архитектуру, или инфраструктуру [4].
Существует еще одна классификация для приложений, в зависимости от роли, которую оно выполняет в рамках портфеля [41]:

критически важное для предприятия в целом;
критически важное для бизнеса;
вспомогательное. Приложение для решения второстепенной задачи;
средства офисной автоматизации.

Для различных компаний одни и те же "стандартные" приложения, могут относиться к различным уровням в данной классификации [41].

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

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

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

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

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

Вот некоторые типичные примеры.

Банковское дело

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

Производство

Работа с клиентами/выполнение заказов
Планирование поставок сырья
Расчет себестоимости по объему хозяйственной деятельности
Отгрузка/приемка/выставление счетов

Транспорт

Разработка маршрутов
Обслуживание транспортных средств
Проезд и размещение клиентов
Учет финансовых ресурсов

Элементы управления портфелем

Успех в управлении портфелем приложений обеспечивают следующие шаги.

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

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

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

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

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

Следует учесть и некоторые дополнительные факторы успешного выполнения проекта:

понимание необходимости взаимосвязей и координированной работы;
выполнение задач строго в рамках проекта;
обеспечение тесного взаимодействия на регулярной основе представителей бизнес-групп с командой разработчиков.

ИТ-проекты в портфелях и программах

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

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

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

В заключение необходимо сказать, что умение управлять портфелями и программами является одним из важнейших критериев зрелости компании с точки зрения внедрения методов проектного управления. В частности, это декларировано в модели зрелости ОРМ3 (Organizational Project Management Maturity Model), разрабатываемой в настоящее время Американским институтом управления проектами PMI в качестве международного стандарта.

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

В Архитектуре приложений выделяют две основные области:

формирование и управление портфелем прикладных систем предприятия;

разработку прикладных систем.

Портфель прикладных систем

Инструментом для описания планов, связанных с использованием ИТ в организации, является Портфель прикладных систем (приложений). Он описывает приложения, предназначенные для выполнения функций организации, для обмена информацией между клиентами, поставщиками и партнерами предприятия в терминах их Роли и Вклада в бизнес. При этом также описываются каналы взаимодействия пользователей с приложениями: web-браузеры, графический интерфейс "толстого" клиента, мобильные устройства и т.д. Управление портфелем прикладных систем тесно переплетается с темой управления ИТ-проектами и ИТ-активами.

Оценка текущего состояния портфеля. Каждая ИТ-система помещается в квадрант, который отражает её ценность для бизнеса.

Обобщенные источники преимуществ для приложений различных типов

Область разработки прикладных систем

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

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

Назначение области разработки прикладных систем

Выбор технологий для построения приложений и способов их применения.

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

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

Контекст управления портфелем прикладных систем

Модели и инструменты управления портфелем приложений

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

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

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

Результаты оценки

системам грозит вывод из эксплуатации (замена) - низкая ценность для бизнеса и плохое техническое состояние;

системы требуют переоценки или перепозиционирования - низкая ценность для бизнеса и отличное техническое состояние (как правило, это недавно запущенные системы, но их вклад незначителен);

системы требуют обновления - высокая ценность для бизнеса и плохое техническое состояние (менять архитектуру приложения);

системы требуют сопровождения и развития - высокая ценность для бизнеса и отличное техническое состояние.

Классификация, связанная с ролью приложения

Критически важное для предприятия (mission-critical). Приложение важно для осуществления всей миссии компании, нарушения в работе приложения могут повлечь катастрофические последствия для бизнеса. Пример: система биллинга оператора мобильной связи или система управления движением в аэропорту.

Критически важное для бизнеса (business-critical). Приложение важно для поддержки отдельного направления бизнеса или бизнес-процесса. Нарушения могут повлечь серьезные затруднения в бизнесе. Пример: система приема заказов через Интернет.

Вспомогательное (utility). Некритичное приложение, решающее частную, вспомогательную задачу. Пример: система резервирования помещений для переговоров.

Средства офисной автоматизации (office productivity). Это приложения, используемые для автоматизации повседневной работы. Пример: офисные пакеты и средства подготовки презентаций.

Особенности использования приложений

Наличие приложений "всех уровней" вовсе не является обязательным. Это зависит от специфики работы предприятия.

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

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

Целесообразной является ориентация на применение отдельных стандартных прикладных компонент (управление пользователями на уровне общесистемных сервисов).

Пять архитектурных стилей прикладных систем:

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

Операции в реальном времени (Real-Time Operations). Примеры: транспортные операции в аэропорту, мониторинг пациентов в клинике.

Аналитические приложения, бизнес-аналитика, поддержка принятия решений (Analytical and Business Intelligence). Примеры: интенсивный анализ больших массивов данных в поисках закономерностей, прогнозирование, принятие решений о выдаче кредита.

Корпоративные и обслуживающие приложения (Utility). Системы ERP, CRM, управления персоналом, расчета заработной платы.

Читайте также: