Название класса программных систем Enterprise Resource Planning содержательно связано с ранним этапом их развития, когда они были предназначены для поддержки плановых расчетов преимущественно машиностроительного производства. Точнее было бы называть их «транзакционными машинами», но по традиции используется не соответствующее сути название — ERP. Словосочетание «транзакционные машины» отражает суть их работы — регистрацию предварительно разработанных и формализованных преимущественно для ручного учета финансовых транзакций. Подобный учет явно или неявно предусматривает использование человеко-машинного интерфейса для ввода, актуализации, верификации вводимых данных и выводимых отчетов. Но за время, прошедшее с момента возникновения первых ERP, ситуация с корпоративным учетом кардинально изменилась. Если в 80-е годы учет был ориентирован преимущественно на стандартные транзакции, причем в минимальном количестве, возможном при ручном вводе и обработке, а нестандартные проводились по особым процедурам, утверждаемым нередко на самом высоком уровне, то сегодня большинство транзакций стандартными можно назвать весьма условно, хотя по-прежнему многие из них можно считать типовыми. Изменение бизнес-среды все больше требует учета «транзакций по запросу», динамически конфигурируемых в зависимости от состава участников и конкретных условий.
Не менее сложная ситуация сложилась и в бизнес-анализе. Человеко-машинный интерфейс ранее обеспечивал надежность представления данных и отчетов в информационных системах. Но когда данные стали попадать в базы, минуя этот качественный интерфейс, возникла проблема достоверности их представления. А дальше стало еще сложнее. Ранее данные попадали в учет только по завершении финансовой транзакции, и, соответственно, согласования данных различных подсистем не требовалось: оно происходило автоматически при обработке документов вручную финансистами и экономистами. Но по мере развития ERP из различных подсистем стали поступать в электронное хранилище оперативные документы, которые относились к незавершенным финансовым транзакциям и попадали в систему в месте возникновения, не пройдя верификацию на должном уровне специалистами финансовых служб и не будучи согласованными между собой. В результате практики стали сталкиваться с парадоксами: например, товар уже продан, хотя не был еще оприходован, так как не получены надлежащие по процедуре финансовые и юридически действительные документы. При этом «генералы от бизнеса» всячески препятствовали попыткам финансовых служб прекратить беспредел, поскольку реально за подобными ситуациями могли стоять кражи и пересортица, с которыми потом разбираться приходилось финансистам, а участники оперативных продаж были вроде бы и ни при чем. Однако нельзя было отказать в логике и «генералам»; ведь товар все-таки появился в складском учете, следовательно, с ним можно начинать операции, и это не без оснований подавалось как преимущество компьютерного учета.
Логика работы современного учета все более напоминает не «магазин учетных товаров», а «сервисный бутик» (Information as a Service, IaaS). Поступающий извне документ передается «на обслуживание» в систему учета, где, в зависимости от ряда критериев, он обрабатывается («обслуживается») теми или иными — возможно весьма различными и не обязательно стандартными — способами. Особое значение приобретает обработка заведомо нестандартных документов, а также формирование транзакционных документов и их обслуживание по уникальному запросу клиента или партнера. Запрос не обязательно может быть связан с единичным производством нестандартного товара. Довольно часто встречается, к примеру, специфическая логистика каждой партии при использовании общедоступных логистических сервисов или различные схемы финансирования сделки. Обработать стандартную транзакцию не сложно, в то время как для организации сервисной обработки необходима весьма высокая и притом надлежащая квалификация персонала, не говоря уже о наборе сервисных инструментов и заготовок от внешних поставщиков сервисов. Понятно, почему «сервисная идеология» обработки сделок не была распространена в бизнесе раньше: без мощной компьютерной поддержки она неприемлемо дорога. А в ИТ идеология поддержки сервисов в широком смысле пока только объявлена и еще далека от стандарта.
Интегрированные корпоративные системы на базе информационных корпоративных сервисов — ИКС2 (integrated corporate system based on corporatelevel information services, ICS2) призваны решить проблемы, которые не под силу ERP. Как надеется ИТ-сообщество, ИКС2 -системы придадут новый импульс развитию ИТ, обеспечив давно ожидаемый «новый» уровень управления информацией. Собственно, первый «икс» (integrated corporate system) терминологически хорошо известен — но, к сожалению, лишь терминологически, так как реальная интеграция различных систем продолжает оставаться чрезвычайно сложной и неалгоритмизируемой задачей. А вот второй «икс» (corporate-level information services) — это действительно новый уровень. Попытаемся раскрыть содержание ИКС2.
Максимально упрощая, в области ERP логику обработки можно обрисовать так: бизнес-сервис — человеко-машинный интерфейс — документы — человеко-машинный интерфейс — данные — человеко-машинный интерфейс — база документов — обработка данных — человеко-машинный интерфейс — предоставление отчетов. Проблемы этой схемы очевидны — документ изменить очень сложно, чужие документы не акцептуются, связи между документами жестко прописаны. Архитектура получается жесткой и плохо модифицируемой, хотя и понятной, не сказать, правда, что простой. Отсюда, кстати, и все проблемы внедрения ERP, особенно в нашей стране. Зато человеко-машинный интерфейс обеспечивает, при надлежащей организации, необходимый уровень достоверности и надежности данных, согласование же данных происходит «по умолчанию» в человеко-машинном интерфейсе.
ИКС2-система предполагает иную логику работы с данными и их превращения в информацию: бизнес-сервис — все данные складируются в базу (хранилище) с признаком «событие» — по запросу (событию) строится документ, проводка или отчет — человеко-машинный интерфейс — верификация — актуализация. В этом случае о достоверности и надежности данных, а также об их согласовании нужно специально заботиться, зато архитектура получается очень гибкой и изменяемой. Возможно применение самой сложной бизнес-логики, в том числе нетранзакционного характера, скажем, моделирование вариантов логистической обработки заказа или партионности его выполнения. Обработку с помощью человеко-машинного интерфейса нужно специально организовывать, но зато можно значительно сэкономить на ресурсах. Однако для обработки в человеко-машинном интерфейсе обычно требуется существенно более высокая квалификация сотрудников.
Рассмотрим в качестве примера типичный случай «проблемной обработки» в ERP. Приходит внешний «мягкий» (то есть не гарантированный к исполнению) заказ на товар. Для того чтобы обработать его в системе, нужно интерпретировать заказ как внутренний документ. Но такой документ не предусмотрен в системе, ориентированной на учет уже свершившихся фактов. Как же в этом случае получить информацию о возможности выполнения заказа и его стоимости? Хорошо, если, скажем, он подлежит интерпретации как плановый заказ, но ведь это далеко не всегда так, например изделие не типовое или логистика нестандартная. Да и плановый заказ порождает слишком большую транзакционную обработку, чтобы его можно было безболезненно «запустить» в систему, например для моделирования себестоимости и срока исполнения заказа. Конечно, существуют специальные системы «заказного производства» для обработки таких ситуаций, где «предполагаемый заказ» как транзакционный документ уже предусмотрен. Но ведь подобная ситуация возникает не только в заказном производстве, да и заказы клиентов становятся все более и более нетипичными и в один документ даже «заказных» систем перестают укладываться.
Логика ИКС2 совершенно иная. Появление события «внешний заказ» порождает конфигурируемую обработку «планирование». Поскольку данная обработка не транзакционная, то есть не порождает действий по финансовому учету, то она не требует верификации на высшем уровне и может быть осуществлена под контролем (ответственностью), скажем, сотрудника планового отдела. Полученные данные по срокам и стоимости верифицируются через человеко-машинный интерфейс, если это необходимо, и согласовываются с клиентом, возможно, без прямого участия человека. Согласованный заказ порождает уже транзакционный заказ клиента, который в свою очередь порождает транзакционную обработку, но, возможно, включающую в себя нестандартные элементы. Правила включения нестандартных элементов и их верификации — это вопрос квалификации персонала исполнителя, и в случае необходимости верификация может проводиться на высшем уровне ответственности. Аналогичная ситуация возникает и при взаимодействии, например, ERP и MES (Manufacturing Execution System), работающих преимущественно с нетранзакционными данными, которые могут легко и часто меняться по производственным причинам. Более того, в определенных ситуациях транзакционные данные могут отличаться от итоговых данных MES, что кардинально нарушает концепцию «статичности» и «однозначности» данных ERP.
Приведенный пример показывает и еще одно существенное различие между ERP и ИКС2. Отчеты в ERP базируются на интерпретации условно-статических данных, полученных в результате учета полностью завершенных транзакций. То, что это проблема, известно уже давно: с появлением «продвинутых» ERP-систем данные в базах перестали быть статичными и всегда связанными с завершенными транзакциями. Известны анекдотичные ситуации, когда представители различных подразделений приносили на всевозможные руководящие совещания самодельные отчеты, в которых, скажем, отгрузка отличалась на весьма существенные величины, и отчаянно отстаивали верность именно своих данных. Когда за подобные ситуации призвали к ответу ИТ-отделы, они, конечно, научились принудительно согласовывать учетные и отчетные данные, но стали ли в результате эти данные более содержательными и достоверными? В ИКС2-системах получение отчета — это сервис, предполагающий все возможные обработки и интерпретации, а также четкую ответственность за их принятие; предполагается также заранее согласованная вариантность представления.
В отличие от ERP, хранилище данных в которых было проблемно-ориентированным, что затрудняло его интеграцию, но упрощало интерпретацию, в ИКС2 -системах архитектура должна быть приближена к стандартной учетной системе. Информация складывается в хранилище в неструктурированном виде, а структурируется, актуализируется и верифицируется по запросу. Для понимания различия этих моделей можно рассмотреть, например «учет» продажи. Для ERP-системы, как для транзакционной машины, главное — учесть финансовые последствия операции и соответственно «оформить» документы, фиксирующие оплату (денежные отношение) и переход права собственности (юридические отношения). Когда-то это был «хороший» учет, так как вся деятельность предприятия сводилась к этим операциям — деньги и товар шли по одному и тому же пути навстречу друг другу в одной транзакции. Но для управления деятельностью в современных условиях этого уже недостаточно. Сегодня производитель может размещаться где-то в Индокитае, а, в результате, физическое (логистическое) движение товара и движение денег оказывается различным, более того, в некоторых случаях вообще имеет разную бизнес-логику, в том числе совершенно разных контрагентов: они являются составными частями различных транзакций. Но при этом их нужно сопоставлять друг с другом, синхронно управлять ими и контролировать. Вот и получается, что транзакционная логика системы — уже не преимущество, а препятствие. Более того, если материальные и финансовые потоки являются членами одной транзакции, то для них уже есть бизнес-правила интерпретации «завершенности» и «сопоставления», и значит, несложно получить «отчет о продажах». А вот если они — в разных транзакциях? Тогда становится очевидным преимущество «сервисной» архитектуры, при которой бизнес-правила уже не привязаны к стандартным транзакциям. Кроме того, снимается типичная проблема ERP — подвисание при обновлении сложносвязанных данных, вызванное вводом нового документа или запуском сложного отчета. Правда, возникает новая — как фиксировать «бизнес-среду» в момент запроса.
Динамическое изменение информации обеспечить сравнительно легко. Гораздо сложнее обеспечить создание «актуального» среза информации по фиксированным бизнес-правилам в момент появления запроса, так как он должен базироваться на интерпретации не полностью завершенных транзакций. Однако выгоды гибкой архитектуры данных в современном коммерческом окружении очевидны. Изменчивость бизнеса и необходимость устанавливать «отношения» с различными партнерами в различных странах, гибко изменять бизнес-логику приложений в зависимости от изменения рыночной ситуации — вот основные причины для перехода на гибкую архитектуру. Не стоит забывать и о том, что участниками бизнес-процессов и поставщиками транзакционной информации в этом случае будут совершенно разные и независимые организации, соответственно у них, скорее всего, будут совершенно разные компьютерные системы и существенно отличающиеся документы — разной структуры и на разных языках. Сегодня часто возникает необходимость учета, планирования и контроля процессов, вообще не имеющих транзакционного (финансового) отражения в управляющей компании.
Конечно, сам факт появления систем, ориентированных на сервисы (Service-Oriented Architecture, SOA), не уничтожает ERP-системы как таковые, но ERP перестают быть ядром корпоративной информационно-аналитической системы, а приобретают более присущее им место статической учетной системы, ориентированной лишь на внешнюю и корпоративную отчетность (системы «посмертного» учета и хранения данных). Живой же тактический и оперативный учет, в том числе и планирование, осуществляется в сервис-ориентированных системах. Иначе говоря, ИКС2-системы предназначены для организации сложной бизнес-логики, прежде всего ориентированной на управление логистическими процессами, а не на финансовый учет, как ERP-системы. Реальность нашего времени такова, что головная компания физически ничего не производит, да и вообще как бы «не касается» материального мира, ограничиваясь управлением своей виртуальной производственно-логистической системой, из которой к ней «текут» вполне реальные финансовые потоки. Но в ИКС2-системе данные, собираемые буквально отовсюду, превращаются в информацию, которая сейчас правит миром. В идеальном варианте ИКС2-системы должны обеспечить гибкое конфигурирование учетно-информационного пространства под изменяющиеся запросы предприятия, не затрагивая транзакционную систему, требования к которой определяются жесткими государственными и корпоративными правилами.
***
ИКС2 — это еще и Х2. Таких систем еще нет, и не доказано, что их вообще возможно создать, несмотря на то, что все крупнейшие производители обещают нечто подобное, манипулируя аббревиатурами, в обязательном порядке включающими букву S (от Service): IAAS, SOA, SOBA и т.д. и т.п. Но очень хочется, чтобы эти системы были созданы, и как можно скорее, так как перечисленные проблемы уже более чем реальны и без их разрешения неудовлетворенность компаний в ИТ вообще и в ИТ-решениях для управления бизнесом в частности будет только расти.
Сергей Колесников (kolsn@inbox.ru) — независимый консультант (Москва).
