Первые успехи во внедрении порталов и мощный фундамент этой технологии вызвали среди ИТ-организаций большое воодушевление. ИТ-группы особенно привлекают ключевые функции, такие, как персонализация, безопасность, сотрудничество, управление контентом и унифицированный поиск, создающие всестороннюю рабочую среду для сотрудников, клиентов и партнеров предприятия и позволяющие им взаимодействовать друг с другом и с другими системами.
Между тем многие предприятия обратили свое внимание на новую методологию управления изменениями и внедрения систем под названием Process Management (PM, управление процессами; не путать с BPM — управление производительностью бизнеса). PM позволяет рассматривать корпоративные системы через призму бизнес-процессов, а не как разрозненные компьютерные приложения, обеспечивая видимость, гибкость и быстроту реагирования, необходимые для оптимального управления бизнесом.
Эти две тенденции породили концепцию гибридных приложений PM/portal (которые также известны как PM-порталы). В идеальном случае PM-порталы предлагают унифицированный доступ к информации и распределительные услуги порталов, интегрируя в них более глубокие аналитические функции и низкоуровневую поддержку принятия решений PM-концепций, а также инструменты измерения бизнес-производительности, такие, как Balanced Scorecard, Analytic Hierarchy Process Роберта Саати, моделирование бизнес-процессов и отображение стратегических контрольных задач (strategic benchmark mapping).
С увеличением числа возможных вариантов создания таких гибридных приложений сообществу разработчиков порталов пришло время всерьез обсудить оптимальные схемы их разработки. Масса практических реализаций показала, что существует немало возможностей интеграции порталов с PM-системами, однако какие же из них достаточно жизнеспособны и действительно предлагают лучшие достоинства обеих технологий?
Новое лицо знакомой технологии
Многие задаются вопросом, не является ли PM-портал всего лишь новым названием для EIP-портала. Однако в то время как типичные EIP-реализации — это «чистые» BI-системы (т. е. фокусируются на хранении данных с бесшовным доступом к приложениям онлайновой аналитической обработки данных), функции PM-порталов выходят за рамки анализа и отчетности. PM-портал закрывает пробел между разнородными источниками информации, операционными системами, системами поддержки принятия решений и инфраструктурой доставки информации в целях эффективного управления бизнес-процессами. BI-компоненты должны быть тесно интегрированы с совокупностью других компонентов, таких, как групповые приложения для поддержки коммуникаций и технологических процессов (workflow) и общекорпоративная инфраструктура обмена сообщениями (например, JMS-платформа), что позволяет осуществлять разработку функций корпоративной интеграции.
По мере того как индустрия все активнее начинает использовать новую модель порталов на базе PM, появляется технологическая архитектура, фундаментально отличающаяся от той, с которой мы хорошо знакомы. Вот наиболее важные характеристики этой новой архитектуры.
Ориентация на процессы в противовес ориентации на хранилище данных. Модель организации данных с основным упором на их хранение уже не является основополагающей. Вместо этого возможности и функции корпоративной ИТ-инфраструктуры вырабатываются в соответствии с определением операций, необходимых для выполнения требований процесса управления бизнесом (как внутри, так и вне предприятия), независимо от задействованных в нем людей или систем. В результате мы получаем архитектуру, которая может поддерживать операции, параллельно протекающие в разных приложениях поддержки принятия решений и операционных системах. Говоря конкретнее, она предоставляет сервисы, интеграцию и связующие функции, которые необходимы для выполнения всех операций, в сумме составляющих полноценный процесс.
Интеграция на презентационном уровне в противовес интеграции на уровне данных. Приложения должны получать доступ к данным так, словно они хранятся в одной базе данных, независимо от того, так ли это на самом деле. Основной целью должна быть интеграция ключевых метрик, показателей и измерений разнородных приложений, а не техническая отладка прямого доступа к различным приложениям. Действуя таким образом, в итоге вы получите гибридную архитектуру, которая является комбинацией виртуального (презентационный уровень) и физического (операционные системы, хранилища данных, витрины данных и т. д.) доступа к данным. Виртуально интегрированные данные должны включать в себя не только структурированные, но и неструктурированные данные — эту возможность обеспечивают управление контентом и программные интерфейсы приложений XML (API, application programming interfaces).
Ориентация на услуги в противовес обособленной природе приложений и аналитических инструментов. Архитектура не предполагает, что пользователи будут взаимодействовать с обособленными приложениями и связанными с ними аналитическими инструментами, как это имеет место в традиционных EIP-порталах. Напротив, она способствует использованию большого количества прикладных компонентов в качестве услуг: технология Web-служб интегрирует компоненты в единое приложение; определения бизнес-процесса играют роль интерфейса сервисных спецификаций для установления того, какие компоненты должны быть включены в Web-службу. Этот подход обеспечит вам в высшей степени динамичную, общекорпоративную (межорганизационную) интеграцию для внутренних и внешних сетей. Он также подталкивает вас к интеграции внутрикорпоративных бизнес-процессов, обеспечивая возможность полного обмена внутриорганизационной информацией и потенциалом бизнес-аналитики, таким, как создание хранилища данных коллективного пользования и Web-служб BI.
Федеративная брокерская модель обмена в противовес монолитной модели «центр — лучи». Модель обмена информацией базируется на принципах федеративной архитектуры, которая допускает использование разнородных «лучших в своем классе» решений. Такой принцип противопоставляется монолитным структурам «центр — лучи», способным обслуживать лишь одно концептуально однородное решение, которое будет слишком жестким, чтобы интегрироваться с более поздними приложениями (например, с готовыми коммерческими продуктами). Федеративная стратегия ускоряет реализацию новых приложений. Монолитные модели «центр — лучи» в теории выглядят привлекательными, однако весьма нежелательны для практического применения.
Чтобы понять, что такое PMпорталы, нужно осознать, что не существует презентационных характеристик или функций консолидации отчетов, которые будут характеризовать портал как PM-портал. Самая важная определяющая характеристика — это базисный слой взаимосвязанных услуг, действующий в портальной среде; инфраструктурный слой, который явным образом обеспечивает автоматизацию программ, благодаря чему достигается следующее:
- визуализация операций, составляющих внутри- и внешнекорпоративные бизнес-процессы, что необходимо для установления глубинных причин возникновения определенных проблем и дефектов;
- мониторинг критических компонентов всего потока ценности с упором на сквозное управление процессами и выявление факторов, дестабилизирующих баланс спроса и предложения по всему течению потока;
- гибкость режима доступа (захват или выталкивание);
- бесшовная интеграция — как виртуальная (на презентационном уровне), так и физическая (например, в операционных системах, хранилищах данных и витринах данных);
- двойные функции измерения эффективности процессов: измерение результативности (насколько процесс соответствует ожиданиям или же превосходит их); оценка производительности (объем ресурсов, задействованных процессом для удовлетворения или превышения ожиданий).
До сих пор у ИТ-организаций было мало возможностей воплощать в жизнь стратегии на базе структуры PM-портала, поскольку при этом им нужно было внедрять многие компоненты с нуля. Последние достижения в сфере серверов приложений и портальных платформ, PM-систем, систем управления контентом и решений для интеграции приложений значительно снизили объем необходимого специализированного проектирования, позволив ИТ-организациям более смело использовать новые PM-возможности.
Успешные реализации портальных приложений PM
Все компании отличаются друг от друга, поэтому не так просто выбрать правильную стратегию для PM-портальных приложений. В этой области не существует простого руководства к действию. Однако если достаточно внимательно отнестись к следующим важным принципам дизайна и разработки PM-порталов, это очень поможет вам в деле создания высокоэффективных PM-реализаций, благодаря которым может повыситься производительность и результативность работы предприятия и его сотрудников.
Оптимальный метод No 1
Разрабатывайте правильную стратегию. Используйте концепцию федеративных архитектур.
Многие организации до сих пор думают, что PM-порталы представляют собой очень крупные проекты, для которых требуется детальное и всеобъемлющее определение архитектуры. Хотя при проведении таких проектов действительно полезно изучить общую картину, архитекторам и дизайнерам лучше использовать мультигенерационный (ориентированный на несколько поколений) процесс планирования. Этот подход предусматривает введение технических функций с учетом характеристик федеративной архитектуры и объединение основных инструментов и приложений во взаимосвязанную цепь. При этом следует уделять особое внимание нижеследующим вещам.
Обеспечение схемы последовательного развертывания: начните с технологического фундамента, который позволяет подключать к системе новые обособленные прикладные модули по мере развития реализации.
Согласование программы бизнес-инноваций с технологическими возможностями для достижения подлинного баланса между двумя подходами к планированию проектов — основанными на потребностях и на наличии инструментальных средств. В старинном споре о том, что должно стоять на первом месте — бизнес-стратегия или технология, правильны оба ответа. Бизнес и ИТ должны использовать общий мультигенерационный дизайн при разработке компонентов бизнес-модели и системной модели портальной структуры PM.
Обеспечение гибкости при выборе протоколов и технологических стандартов. Использование множественных слоев абстракции в федеративной архитектуре ускоряет внедрение и позволяет добиваться оптимального соотношения между реализациями и требованиями. Протоколы и технологические стандарты меняются. Разбиение на уровни позволяет заменить устаревший протокол или технологию с минимальными последствиями.
Непрерывное унифицирование данных — постоянное уменьшение потребностей в интеграции данных путем устранения дублирующихся версий критических данных (например, сведений о клиентах) в таких системах, как ERP или CRM, повсюду, где это возможно и оправданно с точки зрения расходов. Основная цель этого — обеспечение унифицированных средств поддержки и расширения семантического словаря для различных форматов данных в рамках унаследованных и недавно созданных приложений, а также для бизнес-диалектов.
Определение изначального набора функций портала. Решение здесь должно базироваться на модели бизнес-процессов и на том, какие типы данных, измеряющих эффективность процессов, собираются в реальном времени. Основываясь на этих возможностях, можно выбрать аналитические инструменты для последующей интеграции в портал.
Различение функций, имеющих большее значение для специализированного PM-портала (например, визуализация операций и жизненно важных факторов, определяющих бизнес-процессы), и функций, предназначенных для стандартных порталов (поиск, управление контентом и богатые мультимедийные возможности).
Эти рекомендации отражают тот факт, что проекты по реализации PM-порталов не обязательно должны быть слишком дорогими или приводить к нарушению операционной деятельности предприятия. Использование федеративной архитектуры делает PM-решение в высшей степени гибким при работе с бизнес-планами и ИТ-планами предприятия. Другими словами, оно позволяет создавать архитектуру, которая не только прекрасно подходит для текущей ситуации, но и останется столь же действенной в будущем.
Мультигенерационное планирование выходит на новый уровень осознания благодаря концепции федеративной архитектуры. Этот комбинированный подход сокращает многошаговый процесс между созданием PM-стратегий и их реализацией. Он также предоставляет пользователю доступ к точной и согласованной информации об управлении процессами через хорошо отлаженный специализированный портал, что дает преимущества уже на ранней стадии проекта.
Неправильно с точки зрения стратегии было бы сначала фокусироваться на оптимальных подходах к управлению производительностью, а затем смотреть, какой портал может поддерживать эти подходы. Начинайте PM-планирование с определения характеристик портала и автоматизации процессов управления производительностью в рамках этого портала. Начиная работать с PM, вы отправляетесь в долгое путешествие; создавая правильный портал, вы добиваетесь успеха уже на ранних стадиях этого путешествия.
Оптимальный метод No 2
Следуйте принципам композитной разработки приложений.
Из всех имеющихся в вашем распоряжении подходов к процессу разработки гибридных PM-порталов один из наиболее важных — концепция композитной разработки приложений. Существует много терминов, пытающихся выразить суть данного подхода, таких, как EAI-расширение, взаимодействие корпоративных приложений, бизнес-интеграция PM и «сервисная хореография». Однако я предпочитаю определять композитную разработку приложений в полном диапазоне: комбинирование отдельных компонентов существующих процессов с соответствующей бизнес-логикой (из PM-сценариев) в заново смонтированные процессы, а затем представление результатов пользователю в качестве единого («композитного») приложения.
Характеристики композитных приложений могут различаться, и пока что не существует стандартной методологии, помогающей разрабатывать композитные приложения. Тем не менее можно сформулировать ключевые принципы осуществления данной задачи, в частности:
- конфигурация компонентов и координация взаимодействия на базе бизнес-сценариев;
- поток исполнения инициируется событиями и управляется автоматизированными функциями совместной работы и технологических процессов;
- использование автономных, слабосвязанных компонентов приложений, которые могут не знать и не понимать специфики друг друга;
- полное абстрагирование связующих программ и инфраструктурных услуг (таких, как безопасность, базы данных и трансформация потоков данных), которое обеспечивается сервисно-ориентированными коннекторами и соответствующими API.
Оптимальный метод No 3
Обеспечьте презентационное структурирование на базе ролей.Тема создания структуры для основанного на ролях представления затрагивает ряд отдельных аспектов. Первый — это понимание того, что PM-порталы действуют значительно эффективнее, если их презентационные услуги организованы в зависимости от ролей пользователей в соответствии с принципами композитной разработки приложений, что особенно важно для руководителей высшего звена. Можно сказать, что данную практику определяют предметные эксперты (SME). Вы должны структурировать портал в соответствии с иерархией «SME — бизнес-сценарии». Что касается второго аспекта проблемы, он будет освещен в разделе «Оптимальный метод No 4».
Увеличенный SME-охват портальных презентационных услуг неизбежно приведет к увеличению презентационной глубины и специализации аналитических инструментов, что обеспечивает больше преимуществ для всех пользователей.
Оптимальный метод No 4
Осознайте важность визуального управления.
Тема ролевой организации презентационного уровня также предусматривает повышенное внимание к критическим характеристикам визуального управления — визуальным средствам отображения и контроля.
Визуальные средства отображения должны передавать важную информацию о ходе процессов на SME-уровне, гарантируя использование на этом уровне общих аналитических стандартов и стандартов интерпретации данных. Этот подход расширяет области, в которых могут собираться и представляться важные данные о бизнес-процессах, и таким образом оптимизирует число информационных потоков из отдельных процессов, которые должны отображаться в портале в любой момент времени.
Визуальные средства контроля сообщают информацию об отклонениях в работе процессов, также на SME-уровне. Этот подход подразумевает переход презентационной структуры от непрерывного распространения информации с использованием графических техник и связанных с ними отчетов к дискретному распространению информации с использованием сигналов тревоги и уведомлений о состоянии процесса.
Визуальные средства отображения и контроля создают в портале унифицированный визуальный язык — сочетание существенных визуальных средств отображения и контроля, которое обычно называют портальным табло (portal scoreboard, не путать с методом сбалансированных показателей, Balanced Scorecard). Хорошо организованное портальное табло сочетает презентационные функции карт сбалансированных показателей с пространством портальных страниц («недвижимостью» портала) для отображения цифровых индикаторов, контролирующих ключевые операции (обслуживание клиентов, управление стоимостью и доставка), и сигналов тревоги. К примеру, портальная SME-страница по управлению цепочками поставок может показывать наряду с соответствующими сбалансированными показателями индикаторы операций в реальном времени: «отношение числа своевременно доставленных клиентам товаров к общему числу заказов в определенный срок» рядом с показателем «своевременная доставка товаров от поставщиков». Как видно из этого примера, основная цель здесь — упрощение доступа к информации и облегчение принятия решений на основе полученной информации.
Визуальные средства контроля и ролевая презентационная структура позволяют реализовывать самые действенные PM-функции, такие, как управление исключительными ситуациями и функции работы с персоналом, которые поддерживаются многими ведущими workflow-системами, например, продуктом MQSeries Workflow компании IBM, осуществляющим динамическую ролевую маршрутизацию и расширяющим возможности обработки исключительных ситуаций.
Оптимальный метод No 5
Внедрите функции презентационной интеграции в слой интеграции процессов.
Эта тема также имеет несколько аспектов, однако ограничения по объему статьи позволяют мне уделить внимание лишь самому главному из них.
Интеграция порталов часто превращается в невыполнимую задачу из-за необходимости предоставить доступ ко всей информации в едином окне портала, которое состоит из портлетов (мини-окон). Наиболее распространенный метод разработки порталов в наши дни — создание индивидуальной связи между портлетами и приложениями. Другими словами, каждый портлет использует специальный прикладной коннектор (адаптер) для вывода данных из соответствующего приложения. Несложно убедиться в том, что такой метод приведет к созданию множества «межточечных» соединений, особенно когда вы начнете использовать расширенное ролевое презентационное структурирование с множеством бизнес-сценариев. По мере изменения бизнес-сценариев разработчикам придется перерабатывать бизнес-логику, а также коннекторы портлетов (их в особенности), чтобы они по-прежнему соответствовали изменившимся сценариям и прочим бизнес-правилам. Кроме того, им нужно будет выявить и разрешить трансгрессии презентационных элементов. Такие требования, связанные с постоянной поддержкой и модификацией, могут привести к серьезной дестабилизации портальной платформы.
Теперь давайте поговорим о том, чем обычно занимается слой процессной интеграции. Этот слой осуществляет интеграцию событий — он отвечает за то, чтобы каждый шаг процесса (единица работы в процессе бизнес-сценария) имел достаточно информации о процессе в целом, чтобы синтезировать данные и контрольную информацию для эффективного осуществления следующего шага процесса. Хотя интеграция событий в чем-то напоминает концепцию презентационной интеграции информации, в гибкой портальной среде синхронизация информации в соответствии с пользовательскими взаимодействиями может потребовать использования дублирующих интеграционных программ, чтобы данные, собранные для реализации событийной интеграции, удовлетворяли требованиям презентационного слоя. Для устранения такого дублирования интеграционных процессов некоторые поставщики порталов рекомендуют разделить их, выполняя событийную интеграцию в рамках workflow-механизма, а презентационную — через портлеты.
Чтобы решить эти проблемы, архитектура PM-портала должна поддерживать оба вида PM-интеграции — интеграцию событий и интеграцию информации/данных — в рамках единого интеграционного слоя. Такая особенность архитектуры позволяет портлетам в условиях изменения информационных требований не иметь дела с какими бы то ни было коннекторами. В результате можно успешно реализовать единый интерфейс XML API между слоем процессной интеграции и портлетом.
Очевидно, что для этого подхода потребуется совершенно иная технология по сравнению с обычным workflow-механизмом, чтобы можно было синхронизировать все — и события, и презентационный слой. В среде с хорошо отлаженной событийной и презентационной интеграцией портальные серверы должны быть тесно интегрированы с workflow-механизмами. Такой уровень интеграции — это наиболее важный тип интеграции в PM-порталах.
Что предлагает рынок?
В общем случае, когда компании входят во вновь образованные ниши на ИТ-рынке, такие, как ниша PM-порталов, почва, на которой им приходится работать, оказывается не только незнакомой, но и неустойчивой. Тем не менее технологические предложения в этой области приобретают зрелость с такой скоростью, что если вы стремитесь к росту и приобретению конкурентных преимуществ, вам стоит внимательно изучить доступные продукты.
Во-первых, давайте коротко рассмотрим успехи в области стандартизации. Очевидно, что все, что связано с Web-службами, имеет непосредственное отношение к PM-системам вообще и к PM-порталам приложений в частности. Невозможно в этой статье охватить все последние технологические достижения в области Web-служб, однако я не могу не упомянуть по крайней мере следующие. Группа Business Process Modeling Initiative (BPMI, http://www.bpmi.org) выпустила спецификацию языка Business Process Modeling Language 1.0 (BPML, язык моделирования бизнес-процессов). В ней задействовано много важнейших спецификаций для Web-служб, особенно Web Service Choreography Interface. Кроме того, она определяет формальное описание модели для выражения бизнес-процессов (как на абстрактном, так и на конкретном уровне), которые могут быть преобразованы в совокупности частных реализаций, исполняемых в виде BPML-процессов с использованием публичных интерфейсов Web-служб. На рынке появились продукты, поддерживающие BPML 1.0, в том числе Sterling Integrator компании Sterling Commerce (http://www.sterlingcommerce.com) и ARIS Process Performance Manager компании IDS Scheer (http://www.ids-scheer.com).
Кроме того, сейчас BPMI работает над другой очень важной спецификацией, Business Process Query Language (BPQL, язык запросов для бизнес-процессов), в результате чего мы получим стандартный язык для формирования запросов в бизнес-процессах. BPQL позволит предлагать новые интересные функции в PM-порталах.
Во-вторых, необходимо отметить прогресс в области серверов приложений. Ведущие комплексные серверы приложений J2EE, такие, как IBM WebSphere 5 (http://www.ibm.com/websphere) и BEA WebLogic 8 (http://www.bea.com), сегодня практически на грани превращения в интегрированные workflow-системы и PM-серверы, для этого им нужно начать поддерживать BPEL4WS. Они специально предназначены для работы с критическими PM-функциями, такими, как координация транзакций, компенсация и управление событиями на базе взаимодействий.
И, наконец, что можно сказать об автоматизации портальных систем? На этом фронте также наблюдается значительный прогресс. На рынке существует множество генераторов компонентов J2EE и .NET с действительно эффективными функциями для создания портальных компонентов на базе конфигурационных файлов XML. Конечно, такие инструменты никоим образом не выполняют эту работу полностью, однако они могут ускорить выполнение проектов, особенно крупных. Возьмем, к примеру, инструмент Bowstreet Portlet Factory (http://www.bowstreet.com), особенно полезный при работе над проектами на базе WebSphere с большим количеством портлетов. Этот инструмент автоматизирует сквозные процессы при разработке портлетов, от создания функциональности портлетов (включая возможности их пользовательской настройки) и представления портлетов в виде WAR-файлов (Web archive) и до установки полученных WAR-файлов в виде портлетных приложений на сервере. Такие инструменты, как Bowstreet Portlet Factory, хорошо подходят для разработчиков приложений, для которых область разработки порталов относительно нова.
Предприятия по своей природе очень сложны. Использование новых технологий, таких, как сервисно-ориентированная архитектура, Web-службы, PM и PM-портальные приложения, в целях преобразования предприятий — дело еще более сложное. Тем не менее опыт пионеров в данной области показывает, что, овладев этими тонкостями, можно получить невероятные преимущества.
| Марк М. Давидов — старший консультант в Bank of America, имеет степень Ph. D. Области его специализации — разработка приложений, Web-технологии и архитектуры реализаций крупномасштабных систем с использованием порталов, Web-служб и решений для интеграции процессов. Много пишет на тему интеграции корпоративных приложений (EAI) и порталов. С ним можно связаться по e-mail: markdavydov@netscape.net. |
Базовая информация о PM
Базовая информация о порталах
|
