Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Размышления об S-BPM

16.05.12 сообщество BPMS.ru при поддержке МЭСИ провело очередной мастер-класс из серии “BPMS в действии”: методологию S-BPM и систему Metasonic представляла компания “Логика бизнеса 2.0″. Запись мастер-класса выложена на youtube.

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

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

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

Но если отвлечься от этого субъективизма - кому что ближе - то у меня складывается вот какое опасение: мы оказываемся в плену существующего порядка вещей. Мы начинаем думать о том, как нам людей «озадачить», что они должны делать.

Отвлекаясь от нотации, объектно- она там ориентированная или субъектно-, есть два принципиальных взгляда на процессы: inside-out и outside-in. Меня очень привлекает методология outside-in. Это философия: как надо смотреть на бизнес-процесс. Outside-in говорит: надо смотреть со стороны заказчика, как американцы говорят, «одеть тапочки заказчика» и посмотреть на процесс снаружи.

Есть радикально другой взгляд. У меня как-то был случай у заказчика. Посмотрели их процесс (а процесс был такой клиенто-ориентированный), и я задал вопрос: «а где место клиента в вашем процессе»? Ответ меня просто поразил: «а какое дело клиенту до нашего процесса?».

Так вот, у меня есть опасение, что этот субъектно-ориентированный взгляд будет навязывать взгляд inside-out, что его трудно будет привязать к интересам заказчика, трудно посмотреть непредвзято на свой процесс и трудно выявить резервы оптимизации процесса.

Что еще хотелось сказать. В самом начале докладчику, видимо, хотелось погордиться, но меня это напрягло: патентованная методология. Вот есть нотация ARIS eEPC известная и, скажем, BPMN. Мне кажется, что одна из причин, по которой в соревновании между ними известно кто побеждает, в том, что одна открытая, консорциум, стандарт общедоступен, и вторая - проприетарная методология. Все-таки, мне кажется, современный мир больше ориентирован на open source и public domain, чем на проприетарные и патентованные вещи.

По поводу самой нотации: конечно, все очень спорно. Утверждение, что все можно реализовать… не знаю - как можно реализовать цикл по объектам (multi-instance в BPMN), как реализовать таймер, эскалации и прочие веселые вещи? Наверное как-то можно, но боюсь, что это качели.

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

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

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

Здесь же, мне кажется, мы увидели противоположную крайность: здесь отказались от workflow с несколькими исполнителями. Все свели к межпоточному взаимодействию. Но я видел примеры реализации такого подхода: Intalio делает то же самое. У них на диаграмме каждый исполнитель моделируется не дорожкой, а отдельным пулом, и все взаимодействие между исполнителями в рамках процесса моделируется обменом сообщениями. У меня ощущение сложилось, что очень похоже.

Но я должен сказать, что это намного сложнее и намного более трудоемко. Workflow, разложенный по нескольким дорожкам,- это просто, это надежно. Мне кажется, пул в BPMN и субъект здесь - это просто одно и то же, я не вижу разницы. Но тотально везде его использовать… не знаю, мой опыт говорит, что это совсем не просто становится, менее надежно и трудоемко.

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

31.05.12 | Отклики |    

Комментарии (7)

  1. Илья Машков 04.06.12 08:31

    Анатолий, спасибо за отзыв и насколько это возможно беспристрастный взгляд на SBPM! Попробую ответить или хотя бы начать отвечать на затронутые вопросы.
    Прежде всего, субъектно-ориентированная методология – это, действительно, другой взгляд и другой стиль мышления. В Metasonic AG работает несколько моих бывших коллег еще по IDS Scheer, не понаслышке знакомых с процессным управлением, так вот по их словам у людей, уже погруженных в тему BPM, занимает от 3 до 6 месяцев, чтобы перестроить мозги и «въехать» в субъектный подход. Я с ними вполне соглашусь – убедился на своем опыте.
    С моей точки зрения, успешность применения SBPM на практике зависит от правильного выбора области применения нового подхода и инструментария. Наибольший эффект можно получить в процессах, обладающих рядом характеристик.
    • Во-первых, это те процессы, где происходят интенсивные коммуникации между участниками, и где эти коммуникации мало или плохо структурированы.
    • Во-вторых, это процессы, в которых мы потенциально ожидаем высокую частоту изменений, и к которым, соответственно, предъявляются повышенные требования по скорости внедрения этих изменений. То есть одна-две недели от формализации требования до его реализации в системе – это слишком долго для бизнеса.
    • В-третьих, это процессы, стоимость автоматизации и дальнейшей поддержки которых, должна быть невысокой. Для таких процессов Metasonic Suit подходит очень хорошо, как с точки зрения применяемой методологии, так и с точки зрения лицензионной политики вендора.
    В SBPM в противовес подходу «все выстроить-отреинжинирить, со всем интегрировать и по-нормальному внедрить» предлагается другая идея: максимально быстро автоматизировать, начать исполнять и, благодаря возможности контроллинга процессных показателей, начать управлять процессом. Легкость внесения изменений в модель и немедленное отражение этих изменений в процессном приложении позволяют запустить на практике цикл непрерывного улучшения процессов - пусть небольшие, но явные и, что очень важно, измеримые эффекты! Дальше уже можно постепенно наращивать интеграцию и автоматизацию. Конечно, это не подходит для всех процессов, но для многих – вполне приемлемое решение. И риск «оказаться в плену существующего порядка вещей» в таких ситуациях не страшен, поскольку такие внедрения движимы бизнес-целями. Конечная цель - не автоматизация как таковая, а улучшение целевых показателей, по которым оцениваются изменения. Кроме того, здесь внутренний бенчмаркинг или внешняя экспертиза играют такую же роль, как и в «традиционном» BPM, они позволяют взглянуть на процесс со стороны и привнести в него лучшее. Ведь возможность дать каждому сотруднику инструмент изменения своих процессов, с которой ассоциируется «субъектность», не означает автоматически повсеместный произвол.
    Другим важным с практической точки зрения фактором, с моей точки зрения, является возможность наконец-то реально заинтересовать и вовлечь бизнес в управление изменениями своих процессов. Мне часто приходится слышать от менеджеров такие фразы, как «я никогда не дам свободы своим сотрудникам», «исполнитель должен строго следовать своей инструкции» или такие, как «все равно вся автоматизация и моделирование делаются руками ИТ-специалистов», «нарисованные модели бизнес видит один раз – при подписании» и вплоть до того, что «бизнесу ничего не надо», «только ИТ заинтересовано в том, чтобы внедрять что-то новое». Лично мне это грустно слышать. Но разве это означает, что такой порядок вещей нужно принять как данность и не делать ничего, чтобы изменить эту ситуацию? Я понимаю, что между нашей культурой ведения бизнеса, и японским подходом – огромная пропасть. В Японии SBPM пошел, что называется «на ура», поскольку он органично вписывается в кайдзен, который у них в крови. Нам пока далеко до них, но, как известно, путь в тысячу ли начинается с первого шага. Мы уже попробовали ARIS, попробовали BPMN –практика показывает, что определенный спектр задач удается решать, но, к сожалению, вовлечение бизнеса в большинстве случаев не достигается. А без этого ИТ и бизнес по-прежнему остаются, если и не враждебными, то отдельными лагерями. Без этого хорошая эффективность, которую можно было бы получить от этих инструментов, не достигается.
    SBPM, как минимум на идеологическом уровне, нацелена на то, чтобы стать инструментом самого бизнеса. Удастся ли это? Как быстро? В Японии на это ушло около двух лет, сколько это займет в России? Не знаю – практика покажет. Однозначно, что не все созрели для такого подхода. Но продвинутых, инновационных лидеров в российских компаниях хватает. Опять же вспоминается Gartner, с его идеями о том, что акцент в деятельности Владельцев процессов сместится существенным образом на выстраивание коммуникаций в процессе не только внутри своих организаций, но и вовне, а чтобы достичь радикальных улучшений в этом, не обойтись без новых подходов и технологий, поддерживающих «extreme collaboration». SBPM в этом смысле пусть еще не везде на инструментальном уровне, но идеологически очень хорошо вписывается в новые тренды.
    Не соглашусь, что субъектно-ориентированный взгляд будет навязывать взгляд inside-out на процессы. Прежде, чем начинать выстраивать модели процесса в нотации SBPM, проделывается вся предварительная работа, как в любом другом процессном проекте. Никто не отменял определение бизнес-целей и увязку целей/показателей процессов с ними, никто не отбрасывает определение ответственности и полномочий, границ процесса. С этого начинается и в любом проекте внедрения Metasonic Suite. В этом смысле SBPM очень органично дополняет тот же ARIS или любые другие инструменты, позволяющие описать архитектуру предприятия и задать отправную точку проекта совершенствования или автоматизации процесса. Но SBPM предлагает вместо того, чтобы просто отрисовывать сотни и тысячи моделей на детальном уровне (будь то с целью регламентации или формирования ТЗ на внедрение), описывать их сразу в Metasonic Suite и делать их исполняемыми. При этом понятно, что если вы хотите внедрить SAP, то SBPM – не лучший инструмент; это я снова к вопросу применимости.
    Так вот, когда мы определяем границы процесса, ограничения и требуемые результаты, SBPM вступает в действие. Но не в том смысле, что мы поняли состав субъектов, и дальше каждый начал «рисовать» свои процессы, как ему удобно. Нет, все начинается с выделения субъектов и потоков коммуникации между ними, которые по сути отражают все ключевые промежуточные результаты в процессе. И в этом смысле диаграмма коммуникаций оказывается более наглядной, чем весь сквозной поток работ в EPC или BPMN, пусть и разделенный на параллельные дорожки. Во-первых, на ней существенно меньше символов, и это, кстати, само по себе является инструментом снижения сложности при описании непростых процессов. А, во-вторых, те самые коммуникации в SBPM гораздо более прозрачны и наглядны: те, кто рисовал сложные процессы в BPMN или в EPC, в которых присутствуют циклы и коммуникации, прекрасно представляют, что в какой-то момент разобраться во всех стрелках становится уже не просто. Далее, поняв границы и результаты для каждого из субъектов, можно приступать к разработке моделей их поведения.
    Интересно, что существуют научные исследования (если интересно, могу уточнить ссылку), где показано, что взаимодействие в сложных системах с большим количеством субъектов строится таким образом, что интенсивные и сложные коммуникации осуществляются внутри групп из 5-7 субъектов, а коммуникации между группами достаточно простые. Т.е. SBPM идеально позволяет описать сложные процессы через более простые и интерфейсы между ними.
    Что касается простоты нотации, вопросов, как «можно реализовать цикл по объектам (multi-instance в BPMN), как реализовать таймер, эскалации и прочие веселые вещи», сомнений, что это все уйдет в код, то здесь соглашусь лишь отчасти. Да, например, в BPMN можно нарисовать стрелку и обозначить отправку какой-то информации, а в SBPM в силу лежащих в основе формальных моделей нам нужно будет у одного объекта в явном виде нарисовать функцию отправки, а у второго – функцию получения. Но много других «веселых» вещей в SBPM решаются достаточно элегантно и наглядно, и те же таймеры и эскалации настраиваются без какого бы то ни было кодирования. Зато всего 5 символов. Зато их поймет каждый даже без тренингов. Это в качестве аргументов. На практике в итоге каждый выберет свое, удобное ему решение.
    В завершение несколько мыслей на тему того, что «современный мир больше ориентирован на open source и public domain, чем на проприетарные и патентованные вещи». Не очень понимаю, что такого плохого в том, что SBPM запатентована? Да, автор методологии разработал ее и запатентовал. Есть примеры open source технологий, для которых существуют патенты. Патент означает, что создано что-то новое и уникальное. Если говорить про SBPM, то сегодня ученые в разных странах подключились к развитию и теоретической базы, и к реализации инновационных практических разработок на основе SBPM. Сообщество растет, что подтверждается непрерывным ростом количества тем и участников ежегодной конференции S-BPM One (http://www.s-bpm-one.org/index.php?id=124&L=0). То есть SBPM не останется исключительно в рамках одного вендора и не будет «вариться сама в себе».

  2. Anatoly Belychook 04.06.12 10:36

    Илья

    Спасибо за подробный ответ.

    >> В SBPM в противовес подходу «все выстроить-отреинжинирить, со всем интегрировать и по-нормальному внедрить» предлагается другая идея: максимально быстро автоматизировать, начать исполнять и, благодаря возможности контроллинга процессных показателей, начать управлять процессом.

    Все правильно, но “другая идея” - это идея BPM. Попытка SBPM ее “приватизировать” выглядит несколько странно и вряд ли найдет понимание в BPM-сообществе. Во-вторых, “отреинжинирить”, “все со всем интегрировать” - это 90-е: реинжиниринг, завышенные ожидания от ERP, многомесячные проекты в стиле “водопад”… ARIS тоже больше относиться к этому поколению идей.

    Что касается BPMN, то его используют очень по-разному. Все определяется контекстом: кто-то пытается использовать его опять-таки в стиле классического реинжиниринга 90-х - “а давайте мы задокументируем все свои процессы”. Результат немного предсказуем. И совсем другое дело - BPMN в сочетании с концепцией “What You Model Is What You Run”.

    Концепция важнее техники, и я рад, что концептуально мы ратуем за одно и то же. А BPMN или “нотация из 5 элементов” - это, в конце концов, вопрос второй. Полностью согласен: жизнь покажет.

    А.Б.

  3. >> Вот есть нотация ARIS eEPC известная и, скажем, BPMN. Мне кажется, что одна из причин, по которой в соревновании между ними известно кто побеждает, в том, что одна открытая, консорциум, стандарт общедоступен, и вторая - проприетарная методология.

    Небольшой комментарий. Думается соревнования ЕРС с BPMN (точнее наверно с collaboration diagram) нет как такового, т.к. области применения этих моделей зависят от конкретных задач – где-то лучше одна, где-то другая (к слову в ARIS чудным образом реализован BPMN 2.0 со всем «весельем» - хотите малюйте ЕРС, хотите - CD). Посему победа чего-то там над чем–то там еще - это из области мироощущений, а не фактов. Конечно, сравнивать их можно, но параметры, по которым проводить такое сравнение, находятся где-то за областью здравого смысла :)

  4. Anatoly Belychook 09.06.12 00:27

    Ну так уж и за гранью… По свидетельству Брюса Силвера, официальный представитель Software AG, унаследовавшего ARIS, советует новым клиентам пользоваться BPMN вместо EPC. Это, извините, факт.

    Ваш упор на collaboration diagram выглядит несколько странно, поскольку collaboration это, по сути, надстройка над orchestration. eEPC уместнее сравнивать с последним, как мне кажется.

    Что касается областей применения, я лично вижу области, в которых IDEF0 или DFD имеют преимущества над BPMN, но не EPC. Допускаю, что это объясняется моим слабым знанием этой нотации, буду признателен, если Вы конкретизиуете области, где EPC по Вашему мнению имеет преимущества.

  5. >> По свидетельству Брюса Силвера, официальный представитель Software AG, унаследовавшего ARIS, советует новым клиентам пользоваться BPMN вместо EPC. Это, извините, факт.
    Не совсем понятно, про какой факт идет речь, оставим это на совести свидетеля и «подсудимого». Даже если и так, и даже если кто-то советует новым клиентам BPMN, я бы не делал из единичного случая, не привязанного к контексту этого конкретного случая, каких-то глобальных выводов. У SAG столько представителей по миру (только с поглощенной ИДС по наследству сотни две три досталось), мало ли кто и что советует. Да и понять их можно, у SAG вся идея интеграции ARIS и wM завязана на BPMN. Конечно, если клиент покупает wM, то логично предлагать ему сразу строить процессы в BPMN. Но при всем при этом они зачем-то сделали отдельный модуль автоматической трансформацию ЕРС в BPMN CD (а не наоборот), и дорабатывают его усердно. Вопроса, какая нотация для SAG приоритетна, у меня пока не возникает.

    >> Ваш упор на collaboration diagram выглядит несколько странно, поскольку collaboration это, по сути, надстройка над orchestration. eEPC уместнее сравнивать с последним, как мне кажется.
    Почему же? Синхронные/ асинхронные процессы моделируются и в ЕРС. Далеко не так элегантно как в BPMN CD, но тем не менее.

    >> Что касается областей применения, я лично вижу области, в которых IDEF0 или DFD имеют преимущества над BPMN, но не EPC. Допускаю, что это объясняется моим слабым знанием этой нотации, буду признателен, если Вы конкретизиуете области, где EPC по Вашему мнению имеет преимущества.
    Несколько слов о BPMN.
    BPMN - больше орудие консультантов, чем инструмент, который будет жить и развиваться самостоятельно в компании после их ухода. Вся причина – сложность нотации. Уверен можно научить людей моделировать в BPMN. Но в любом случае процент тех людей, которые в компании будут понимать смоделированное, будет ничтожно мал, а для чего тогда все эти модели? А дальше происходит следующее – либо инициатива моделирования процессов в BPMN отмирает, либо становится примитивной, такой себе урезанной версией (мне уже ни раз приходилось такое наблюдать). Но вся прелесть BPMN как раз в его сложности – хореография, прерывающие события, компенсации и прочие прелести – это то, в чем есть весь потенциал этой нотации, и это то, чего либо нет в ЕРС, либо приходится «извращаться», чтобы эти моменты смоделировать. Но, сложность – это цена наглядности и понятности, и как следствие - распространения. Поэтому первый момент, где ЕРС выгоднее смотрится, чем BPMN – это наглядность. Приведу пример – был у нас один заказчик, у него на отделениях у каждого клерка был доступ к моделям процессов, и если он не знал, как выполнить ту или иную операцию – он открывал web-портал, и смотрел свои действия на ЕРС модели. Да, на модели не было хореографии и прочего – но она ему и не нужна! Ему надо знать, к примеру, кому он должен передать на согласование документ – начальнику отделения или в главный офис, если скажем сумма кредита больше установленного лимита. В ЕРС – это шаги 1,2,3 – а клерку, который не редко вчерашний студент, с низкой з/п, больше и не надо! Как бы процесс согласования был бы смоделирован в BPMN? Пулы, обмен сообщениями и т.д. – оно надо простому смертному? Простота и наглядность – это то, где BPMN не так силен, как ЕРС.
    Второй момент, где ЕРС сильнее BPMN – разработка ПО в части подготовки ТЗ. В ЕРС есть то, чего нет в BPMN – слой данных, слой информационных носителей, слой ИТ (системы, сервисы), причем увязанных меду собой. В BPMN ничего подобного нет, точнее есть data objects, но поскольку они слабо проработаны, то и встретить их на BPMN-моделях можно редко, это скорее такие себе разновидности текстовых аннотаций. ТЗ из моделей ARIS (и EPC в частности), полученное скриптами, вполне стандартный рабочий инструмент, а все за счет интеграции различных информационных срезов.
    Третий момент – интеграция процессов. В ЕРС вы можете смоделировать, с какими процессами связан данный процесс и какими входами/выходами данные процессы обмениваются. Единственный способ борьбы в BPMN с этой бедой – это текстовые аннотации, но их поддержка в ручном режиме удовольствие на грани реальности. Даже когда скриптами автоматизируешь расстановку этих текстовых аннотаций (в ARIS по крайней мере мы этот момент автоматизировали), все равно остается в BPMN вопрос со входами/выходами.
    Четвертый – регламентация – как частный случай второго момента, тоже за чат интеграции различных информационных слоев: оргструктуры, данных, информационных носителей, ИТ, материальных ресурсов. В BPMN этого можно сказать, что нет – есть data objects, но как я уже писал, они в каком-то «не доделанном» состоянии, есть конечно дорожки, но и их интеграции с оргструктурой тоже пока весьма не четкая.
    Ну и еще очень важный момент – это ВРА, который как раз возможем в ARIS все за счет той же интеграции информационных слоев на ЕРС. Это и ФСА, и симуляция, и оценка загрузки персонала по процессам. Это конечно все можно реализовать и в BPMN, в частности в ARIS можно для активностей определять FAD модели (такая себе получается ЕРС в BPMN), но это уже, простите извращение.
    P.S. В этом году ЕРС исполняется 20 лет, BPMN 2.0 – принят в окончательной редакции только в прошлом году, поэтому вопрос распространенности и применимости на сегодняшний момент у меня сомнений не вызывает. Что будет дальше – посмотрим, не исключаю, что лет так эдак через 5 SAG вообще откажется от ЕРС (сомневаюсь конечно, но кто их знает), а к тому времени выйдет BPMN 4.0, в котором будут реализованы все не достающие на сегодняшний день моменты. Посмотрим.

  6. Anatoly Belychook 10.06.12 08:53

    Александр

    На Ваше восприятие BPMN явно повлияло слишком плотное знакомство с ARIS.

    Прелесть BPMN не в сложности, а в методологической нейтральности - его можно использовать очень по-разному.

    Наворотить диаграмму с пулами и сообщениями и жаловаться на сложность? Как знакомо! Вот образчик http://www.finexpert.ru/view/prostye_skhemy_biznes_protsessov_za_i_protiv/775 Там в конце мой развернутый комментарий и альтернативная диаграмма. Это проблема аналитика, а не нотации.

    BPMN орудие консультанта?! Это даже не смешно. А ARIS пользователи сами выбирают невзирая на сопротивление консультантов ))

    Что касается мнений экспертов, то конечно дело не в мнении одного из руководителей SAG. Оно хотя и примечательно, но это всего лишь штрих. По-настоящему важно то, что BPMN - стратегический выбор в области BPM таких гигантов, как IBM, Oracle, SAP.

    У ARIS конечно много преимуществ, но у BPMN есть одно, которое их перекрывает: What You Model Is What You Run.

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

  7. Viacheslav Dobromyslov 19.06.12 13:50

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

    По поводу S-BPM с одной стороны мне понравилось, когда нужно оптимизировать работу внутри отдела компании. Но не понравилось, когда нужно выйти за рамки компании.
    И такое чувство, что у ребят из Бизнес Логики еще не прошла эйфория, начавшаяся вот с таких строк под заголовком S-BPM is conquering Russia:
    A German-Russian alliance intends to get Russian companies ready for the future. The goal of the participating companies, Metasonic and Business Logic 2.0, is to bolster the local economy by optimizing business-critical processes, thereby saving millions in costs. The plan is based on the bundling of advanced ECM (enterprise content management) and BPM technologies. The experts at Business Logic 2.0, a subsidiary of the I.T. Group, are considered the leaders in ECM-BPM integration. With its subject-oriented business process management (S-BPM), Metasonic has developed a technology that is already considered by experts to be the successor to the BPM systems currently in use and has already been successfully adopted by prestigious companies such as Audi, NEC and Hitachi.

    Наверное немцы еще не осознали своей очередной ошибки завоевания России:)

Комментирование закрыто

Copyright © 2008-2024 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии