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

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

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

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

Эта методология получила название MRP (material requirements planning); изначально она была ориентирована преимущественно на проблемы сборочных, или «дискретных», производств. MRP-системы не были «жесткими» по происхождению, так как предназначались для моделирования потребностей производственного плана, но их возможности принципиально лимитировались ограниченными вычислительными мощностями тех времен.

Достаточно быстро была разработана аналогичная методология для планирования производственных мощностей; ее назвали CRP (capacity requirements planning). Правда, уровень сложности решаемых с ее помощью задач оказался существенно более высоким, чем при использовании MRP, но в большинстве простых CRP-систем эта сложность не учитывается. Дело в том, что обычно производство имеет некоторый «задел» мощности, что «сглаживает» проблемы. Для более критичных для бизнеса процессов были разработаны специализированные системы планирования, учитывающие особенности загрузки рабочих центров и их ограниченную мощность.

Объединенная система планирования MRP-CRP получила название MRP II (manufactory resource planning). Совместное планирование материальных потоков и производственных мощностей позволяет поднять всю систему планирования на качественно новый уровень. Но одновременно система приобретает существенную «жесткость», поскольку для более или менее точного определения финансовых результатов сформированного производственного плана необходимы достаточно четкие цели, достоверная информация о запасах, стоимостная оценка материалов, сырья и комплектующих.

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

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

Интегрированные бизнес-системы третьего поколения, родившиеся в середине 90-х годов и получившие название ERP (enterprise resource planning), поддерживают все основные плановые и учетные процедуры крупного производственного предприятия. Основой учета в данном случае является внутренняя финансовая транзакция, поэтому в западной литературе такие системы часто называют «транзакционными».

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

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

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

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

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

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

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

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

Рис. 1. Логистический домен

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

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

Рис. 2. «Развал» стандартной транзакции

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

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

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

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

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

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

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

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

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

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

Сергей Колесников (kolsn@inbox.ru) — директор по консалтингу компании «Экон-профи» (Москва).