Введение.

В наступающую эпоху Интернета компания, не имеющая Web-стратегии, вообще не имеет никакой стратегии. Процессы и цепочки добавленного качества (add value chains) быстро эволюционируют, по мере того как компании берут курс на аутсорсинг, т.е. избавляются от второстепенных функций, передавая их на сторону. Это приводит к формированию более «искушенных» рынков и к более широкому распределению экономической деятельности. Иными словами, способ ведения бизнеса претерпевает стремительные изменения. В какой бы отрасли вы ни работали, это не имеет значения: с развитием технологий, выходом на рынок новых игроков и появлением новых форм, бизнес-партнерства, ниспровергающих существующие правила игры, преобразования происходят все быстрее.

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

Автоматизация процессов в XXI веке.

Сейчас уже все мы знаем, что Web — именно та дорога, которая ведет в будущее. Более того, фирмы стремятся использовать те же Web-технологии для координации внутренней деятельности и привлечения опыта и знаний своих сотрудников. Это позволяет сократить затраты и повысить эффективность. Однако электронная коммерция — это не просто пакет программ для выполнения функций покупки или продажи, который «пришпиливается» к существующим системам. Умело руководимые фирмы используют Web для прямой связи своих бизнес-процессов, интегрируя партнеров непосредственно в систему поставки продуктов и услуг клиентам.

Интеграция современного бизнеса.

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

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

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

Теперь аналогичные идеи прорабатываются и предприятиями сферы обслуживания (на которые в США приходится 80% занятой рабочей силы). Процессы, которые некогда воспринимались как внутреннее дело компании, теперь должны охватывать всю цепочку добавленного качества

. Эффективные поставщики услуг интегрируют свои операции непосредственно в процессы клиентов.

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

Вместо того чтобы прятать проблемы от посторонних глаз, прикрывая изъяны своих процессов, смекалистые фирмы учатся жить в «стеклянном доме». Они совершенствуют процессы, а затем выставляют их на всеобщее обозрение, подавая это как преимущество для клиентов. Пожалуй, наиболее известными представителями этой тенденции являются фирмы FedEx и Dell. Сократив число клиентских запросов, обрабатываемых операторами, эти компании существенно сэкономили на издержках. Приблизительно 20 тыс. клиентов Dell еженедельно проверяют состояние своих заказов, каждый раз экономя при этом компании 8 долл. на административных расходах. Кроме того, когда клиенты сами контролируют состояние их заказа или пакета заказов, они реже раздражаются, что ведет к повышению общего уровня удовлетворенности клиентов.

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

Опираясь на такие тесные торговые отношения, современные формы бизнес-партнерства искореняют дублирование, отфутболивание и брак в работе, обеспечивая гладкое и эффективное функционирование процессов. Первопроходцами в этой области стали такие компании, как Levi. Непосредственное управление запасами клиентов позволило LeviLink Services сократить время пополнения запасов с 14 до 3 дней, а время доставки — с 9 до 3 дней.

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

Куинн формулирует это так: «Используя развитую систему аутсорсинга и новые методы электронных коммуникаций, моделирования и мониторинга, компании могут на 60-90% сократить время и стоимость цикла создания нового продукта, на столько же уменьшить затраты на инвестиции и риски и на несколько порядков повысить ценность своих новинок»

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

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

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

Влияние на процессы.

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

Но мы также должны помнить, что компании не могут себе позволить полностью переделать свои приложения: все устоявшиеся предприятия вложили в используемые системы огромные средства (которые только в США по совокупности оцениваются в сумму свыше триллиона долларов). Они не могут просто так выбросить их на ветер.

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

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

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

Тщетность традиционных подходов.

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

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

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

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

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

Современные подходы позволяют приложениям «обертывать» информацию, передаваемую по заданному маршруту, вычленяя нужного участника для данной бизнес-ситуации и направляя ему работу и связанную с ней информацию, где бы он ни находился. Этот подход опирается на возможности каталоговых серверов, таких как Microsoft Active Directory в Windows 2000 и Lightweight Directory Access Protocol (LDAP). Теперь рабочий объект можно посылать непосредственно клиенту по электронной почте, предоставляя ему уникальную связь для входа на сервер и выполнения следующего этапа процесса.

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

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

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

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

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

Ценность приложений.

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

Однако большинство систем workflow «старого образца» возлагают на разработчика тяжкое бремя составления программных интерфейсов, предназначенных для поддержки взаимодействия с другими системами. Именно здесь обнаруживается «неискушенность» сложившихся подходов workflow. Интеграция стороннего приложения зачастую составляла до 80% от общего объема проектных работ. Однако необходимо принять во внимание, что, используя современный механизм поддержки процессов, систему с определенным набором функциональных возможностей в среднем можно получить примерно за 50% времени, требующегося для разработки эквивалентной системы с нуля.

В исследовании, которое мы провели для одного крупного международного банка

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

Эти цифры типичны для предыдущего поколения систем управления workflow.

Современный подход заключается в разработке интерфейсных адаптеров, которые позволяют системе workflow скрывать от пользователя сложность основных систем, инкапсулируя и «обертывая» приложение. Одновременно это дает фирме возможность эффективно использовать уже сделанные инвестиции.

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

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

Другим аспектом корпоративной гибкости является способность быстро приспосабливать продукт к потребностям конкретного клиента, т.е. наладить индивидуальную настройку в массовом масштабе. Современные системы workflow и в этой области обеспечивают превосходную поддержку. Наилучшим вариантом здесь является подход, который иногда называют Case Handling Systems (системы обработки ситуаций). Суть его состоит в разработке фрагментов бизнес- процесса с привязкой соответствующих функций к приложению. Готовые фрагменты комбинируются «на ходу» с учетом потребностей каждого клиента. Вместо того чтобы каждый раз конструировать все более сложные комплексные решения, фирма может предоставить аналитику (или клиенту) выбрать наиболее подходящие элементы и объединить фрагменты процесса в связное целое. Подход, в основе которого лежит выбор фрагментов процесса для создания единого целого, способствует дальнейшему снижению стоимости владения.

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

Стратегический выбор: разрабатывать самим или покупать?.

Для фирм, занимающихся разработкой приложений, будь то независимые поставщики программного обеспечения (ISV) или крупные конечные пользователи, необходимо рассмотреть ряд аспектов, поскольку разработка корпоративной системы workflow будет иметь серьезные последствия для компании, ее стратегий развития и маркетинга. Ключевыми здесь являются следующие вопросы:.

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

■ Хочется ли вам тратить время на разработку корпоративной системы workflow, пока другие пожинают преимущества быстрого выхода на рынок?.

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

■ Какие последствия повлечет за собой срыв сроков реализации проекта и упущенные из-за этого рыночные возможности?.

■ Какой объем дискреционных ресурсов будет иметь наибольший эффект для доходности и доли рынка вашего предприятия?.

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

Крупные конечные пользователи давно усвоили, что лучше, предоставив заниматься такой разработкой другим, покупать технологии инфраструктуры и интегрировать их с существующими приложениями. Разумеется, бывают исключения. Так, один британский банк решил разработать собственную систему workflow для поддержки широкого спектра имеющихся у него приложений. Однако пользователи в отделах нашли эти системы трудными для модификации и адаптации: внесение изменений в одно стандартное письмо обходилось в кругленькую сумму — 6000 долл. Банк, обнаруживая все новые недостатки доморощенных систем поддержки процессов, потратил несколько миллионов долларов, прежде чем решил наконец прибегнуть к услугам организации, специализирующейся на подобных системах.

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

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

Кроме того, возникли опасения, что самостоятельная разработка может быть сопряжена с другими факторами риска, которые труднее выразить в количественных показателях. Когда составлением спецификаций занимаются люди, имеющие мало опыта в области поддержки процессов, вряд ли можно ожидать, что все необходимые функции будут описаны в полном объеме. При внедрении программного обеспечения разработчики неизбежно будут выбирать кратчайшие пути, позволяющие быстрее получить решение. Но это пойдет в ущерб созданию более универсального решения, которое было бы применимо к более широкому спектру ситуаций. При подходе «разрабатываем сами» разработчики также рискуют завести свое приложение в тупик, в то время как индустрия вместе с клиентами уйдет вперед. В конце концов, компания склонилась в пользу продукта, разработанного на стороне. Бе- та-версия программного обеспечения была готова через 6 месяцев, а еще 2 месяца спустя компания выпустила свой продукт на рынок. Иными словами использование надежного продукта workflow сократило время вывода на рынок по крайней мере на 50%. Более того, когда приняли в расчет дополнительно полученные функциональные возможности, о которых компания и не помышляла, руководители порадовались принятому решению, казавшемуся поначалу не бесспорным.

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

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

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

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

Заключение.

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

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

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

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

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

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

Разумеется, все эти функции должны доставляться и подаваться через Web-интерфейсы. Универсальным пользовательским интерфейсом является вездесущий Web-браузер. Наличие стандартных функций на клиентской стороне играет важную роль, позволяя фирмам быстро внедрить систему в эксплуатацию. Однако как только это сделано, возникает новое требование — обеспечить возможность адаптации и эволюции этого пользовательского интерфейса. Собственно говоря, некоторым организациям понадобится внедрить эти функциональные возможности в специализированные приложения с самого начала. Здесь незаменимую роль играют интерфейсы прикладного программирования (API) и комплекты разработчика программного обеспечения (SDK).

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