ЕRP потеряли, a SOBA еще не приобрели

Кандидат на универсальный интерфейс уже объявлен и выглядит: вполне привлекательно. Речь идет о так называе­мой архитектуру, ориентированной на сервисы (service oriented architecture, SOA), и, соответственно, об ориентированных на сервисы биэнез-прилажениях (Service oriented business application, SOВA). С одной, стороны, это естествен­ное развитие Iatemet-решений для бизнеса, с дру­гой рост интереса к, SOA во многом определяется поддержкой ноной идеологии информацион­ных систем крупнейшими игроками ИТ-рынка, такими как IBM, Microsoft и SAР. Вероятно, они ви­дят возможность монополизировать стандарты на огромном потенциальном рынке.

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

Рассмотрим идею SOBA с точки зрения современной бизнес-практики

Первая проблема, «подкосившая» победный на первый взгляд марш ERP, — отраслевая специ­фика. Дело в том, что МRР II, ставшая основой для первых ЕRР, — это методоло­гия планирования дискретных, большей частью машино­строительных производсв. Но некорректная реклама и отсутст­вие на Запале общедоступного опыта, связанного с разработкой стандартизованных систем планиро­вания производств различных типов, привели к многочислен­ным неудачным попыткам внедрения систем на других производствах, фактически не поддерживаемых плано­вым механизмом MRP П или его близких аналогов.

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

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

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

За последние годы процесс переноса лидерами рын­ка своего производства в сграны Индокитая, Ла­тин­ской Америки, Восточной Европы стал массовым. Пи этом в большинстве случаев осуществля­ется перенос именно на территорию субподрядчиков, то есть третьих фирм, не входящих непосред­ственно в холдинги «производителя». Более того, товар доставляется, распределяется и прода­ется также треть­ими фирмами. Другими словами, в от­личие от ситуации, которая имели место в пору создания ERP, сейчас продукция и финансовые потоки не проходят непосредственно через предпри­ятие, что, однако, не сни­мает с бизнеса задачу координации и управления потока­ми. Естественно, подобная конфигура­ция никак не укладывается в стандартную ERP-систему, работающую только с внутренними данными предпри­ятия.

Для поддержания деятельности и сложных финансовых и производственных холдингов, многоуров­не­вых дистрибьюторских систем, транснациональных корпораций и объединений были разработаны спе­циальные методологии управления товарными потоками. Подходы к таким системам управле­ния были зафиксированы в концепции логистических цепочек (supply chain). Сегодня она явля­ется до­минирующей концепцией управления бизнесом реального сектора. Типичной стала весьма слож­ная кон­фигурация логистической цепочки (рис, 1), Некую совокуп­ность возможных участников логи­стиче­ских цепочек конкретного предприятия можно назвать «логистичес­ким доменом».

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

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

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

В за­висимости от конкретной ситуации одинаковая по структуре логическая транзакция (скажем, заказ то­вара на заводе в Китае, доставка на таможенный склад в Финляндии и дистрибу­ция оттуда по Рос­сии) может происходить при участии (посредничестве) различных участии ков домена. А значит, воз­можны различные финансовые схемы, логические процедуры, протокола взаимодействия. В таком контек­сте теряется принципиальная для обычных транзакционных систем взаимосвязь финансового и матери­ального потоков.Критическую роль обретают информационные пото­ки, не связанные напрямую для головной компа­нии ни с финансами, ни с товаром. Так, с точки зрения управления логистической пеночкой крайне важны "Потенциальные» заказы клиентов или информация о новинках рынков сырья, материалов и комплектующих, а также пока труд­нодоступная аналитическая информация (в частности, постоянно актуализируемые данные о динамике спро­са в торговых точках но отдельным товарам и товарным труппам).

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

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

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

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

Итак, перечисленные проблемы ни поодиночке, ни в совокупности не могут быть решены за счет модерниза­ции «внутренних» систем, которыми являются ERP-системы. Они требуют перехода к «гиб­ким» динамически взаимодействующим системам, компоненты которых опираются на стандарт­ные протоколы взаимодействия и передачи данных. Видимо, поэтому в компании Gartner и посчи­тали, что ERP-системам осталось жить совсем не­много.

Россия, не выбросив на ERP сотни миллионов, а то и миллиарды долларов, сделала очень разумный шаг. Теперь можно будет вложить средства в действительно современные системы, которые могут стать существен­ным стимулом развития бизнеса и ИТ в будущем. Однако необходимо дождаться появления работоспособных ре­шений «в стиле SOBA» и утверждения, хотя бы де-факто, стандартов SOA. К сожалению, опыт интеграции ERP-приложений оказался не то чтобы неудачным, но уж очень непростым. А это, конечно, затруднит внедрение новых идей приложений, ориентированных на сер­вис.

Возвращаясь к аналогии с мэйнфреймами, можно предположить, что мы не сразу получим откры­тую, сво­бодно интегрируемую архитектуру SOA. Скорее всего, на первых порах это будет архитек­тура, ориентирован­ная на интеграцию с некоторым базовым приложением и аналогичная сущест­вующим решениям, скажем, от Microsoft или SAP. Некоторое «материнское» приложе­ние будет иг­рать роль мэйнфрейма, а для взаимодейс­твия с ним будут предоставляться частично стандарти­зо­ванные, или «полуоткрытые», интерфейсы и сервисы. Взаимодействие же между различными мате­ринскими при­ложениями будет по-прежнему представлять про­блему или ограничиваться узкими рамками общепри­нятых стандартов.

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