Учебное_пособие_ТИПиС и Глоссарий. Учебное пособие для студентов очной и заочной форм обучения представляет собой подборку материала по курсу Теория информационных систем и процессов
 Скачать 5.1 Mb.
|
6.5. ERP и BPMS.ERP дословно означает Enterprise Resource Planning – Планирование Ресурсов Предприятия. BPM – Business Process Management – Управление бизнес-процессами. Различия и частичное пересечение между этими двумя концепциями – свидетельство общего тумана вокруг взаимоотношения процессов и бизнес-приложений. Если у вас есть ERP-вендор, это еще не означает, что у вас есть достаточно хорошая процессная составляющая. И если у вас есть BPM-вендор, то это не означает, что вы сможете построить ERP функциональность с его помощью. Наличие платформы от вендора не является достаточным ни для управления процессами, ни для создания на ней ERP функциональности. Организация может хотеть иметь у себя базовое ERP приложение, дополненное отличной процессной функциональностью. Также организация может захотеть надстроить стандартную платформу, и мириться с отсутствием процессов. Или же организация может захотеть сочетать лучшее из обоих миров. Между пакетными приложениями и управлением процессами сплошная неразбериха. Вендоры приложений теперь провозглашают себя BPM-игроками. Поставщики платформ заявляют, что они снабдили их существенным интеллектом, так что они могут поддерживать управление компонентами приложений/сервисами. Независимые BPMS-вендоры утверждают, что могут обеспечить легкую кроссплатформенность, поддержку растущего числа процессов, берущих начало от вертикальных или горизонтальных процессов, и поддержку сервисов приложений плюс интенсивные процессы с участием людей. Короче говоря, они объединены общим схожим направлением, но есть существенные разногласия в деталях вокруг фокуса, синхронности, совместимости и лучших практик, которые различают эти три класса вендоров. В действительности, большинству организаций необходимы все три типа – даже если области их пересечения продолжат расти, они не сольются полностью. Взгляд с точки зрения ERP/готовых приложений: в моем приложении есть процесс. Процессы – это возможность встроить в приложение лучшие практики, и BPM – это обоснованная часть программной инфраструктуры. Давайте исследуем уровень процессной функциональности в пакетах приложений. Они главным образом сфокусированы на поддержке транзакций и полностью автоматических (straight-through) процессах. Большинство вендоров пакетных приложений слабо поддерживают процессы с участием людей и не сфокусированы на управлении взаимодействием между людьми. Лишь немногие достигли истинной гибкости. Да, некоторые поддерживают сервис-ориентированную архитектуру (SOA), но SOA – это только часть гибкости. С другой стороны, они будут продолжать задавать рынку солидное сервисное/компонентное направление, но большая часть существующей функциональности их приложений пока не оптимизирована для их новых платформ. Пока все еще существует сильная привязка правил и процессов к транзакциям приложений, большинство вендоров готовых приложений будут использовать свою новую процессную функциональность вокруг уже существующей основной/стандартной функциональности. Вещь хорошая, но недостаточная – за исключением организаций, находящихся на завершающей стадии жизненного цикла. Взгляд со стороны BPM: в моем процессе есть прикладные/композитные сервисы. Приложения – это транзакции, которые могут быть встроены в дифференцирующие и гибкие процессы. Давайте проверим уровень лучшей практики здесь. Процессные вендоры предоставляют мощную процессную платформу, которая обеспечивает большую гибкость и функциональность главным образом вокруг ситуационного менеджмента, управления контентом и совместной работы, но организациям недостает лучших практик «из коробки». Исключение из правил – BPMS вендоры, которые предоставляют процессы высокой степени готовности и/или обеспечивают доступ к каталогам сервисов готовых приложений и позволяют воспользоваться большим числом стандартных транзакций готовых приложений, а также, через «обертки», унаследованными приложениями. Для организаций, которые считают, что отличные процессы дают больше, чем самые лучшие транзакции, процессные вендоры будут весьма привлекательны. BPM вендоры по-прежнему будут превосходить вендоров приложений в части поддержки работников интенсивного умственного труда и исполнителей бизнес-процессов, и в ближайшее время я не ожидаю сокращения этого отставания. Драка будет идти за накопление интеллектуальной собственности и за привлечение достаточного числа партнеров, которые смогут обеспечить такое накопление на новой процессной платформе. В итоге. Гонка идет за то, чтобы выяснить какой класс вендоров станет лучшей платформой – с самым длинным списком наилучшей бизнес-функциональности, политик/правил и контента. Организации вправе ожидать, что BPM вендоры продолжат движение в сторону связи с множеством справочников и использования богатого наследия множества платформ. Ключевой вопрос для этих вендоров – способность создавать первоклассные шаблоны и паттерны быстрее, чем вендоры готовых приложений будут менять свои платформы и трансформировать свои первоклассные транзакции, компоненты и композитные приложения. В качестве комментария: BPM недостаточно. Множество ИТ-специалистов и конечных пользователей, с которыми я имел дело, работая у BPM-вендора, постоянно спрашивали меня, «Зачем нужнаBPM-система, если у нас внедрена ERP?». В самом деле, хороший вопрос. Как-никак, ERP подразумевают интеграцию и автоматизацию бизнес-процессов. А теперь некоторые лидирующие поставщики ERP даже сделали workflow-системы частью своих предложений. Так какую же ценность приносят BPM-системы? BPM-системы позволяют организациям управлять (определять, исполнять, контролировать, мониторить и совершенствовать) бизнес-процессами независимо от внедренных в ней бизнес-систем (ERP, SCM, CRM и т.д.). В этом и следующем посте я попытаюсь ответить на вопрос «зачем нужна BPM-система, если у нас внедрена ERP?». BPM-системы оркестрируют бизнес-процессы. BPM-системы исполняют бизнес-процессы от начала и до конца, пытаясь объединять действия в рамках процесса. Workflow-сервер BPM-системы передает работу от одного исполнителя (конечного пользователя) другому. Таким образом, исполнитель знает, в какой момент времени какая работа ему назначена, какой приоритет присвоен этой работе и в какой срок она должна быть выполнена. Таким образом, BPM-система управляет действиями и процессами. С другой стороны, ERP системы – это транзакционные процессные системы, которые автоматизируют транзакции и осуществляют интеграцию данных между различными функциями, но не справляются с оркестровкой бизнес-процессов от начала и до конца. Рассмотрим для примера процесс «Заказ на закупку», который может включать в себя выполнение в ERP-системе таких транзакций, как «Оформление документа заказа», «Оформление документов на отгрузку», «Оформление счета». На практике, эти три транзакции могут исполняться тремя разными исполнителями офиса продаж, склада и бухгалтерии последовательно. ERP-системы избавляют от необходимости дублирования ввода данных этими тремя исполнителями, однако они никогда не сигнализируют складскому работнику или бухгалтеру, что предыдущее действие было закончено и их очередь закончить транзакцию. Следовательно, исполнителям требуется напоминание извне (ручное вмешательство) чтобы это назначенное им задание оказалось выполнено. BPM системы дают контроль над бизнес-процессами и повышают производительность. Исполнение бизнес-процесса в «не-BPM» среде не обеспечивает наглядность ни исполнителям процессов, ни ответственным. Как сказано выше, исполнители процесса не знают, когда работа им назначена, им также неизвестны приоритет и срок исполнения назначенной работы. Подобным же образом ответственный за процесс не подозревает о «бутылочных горлышках», задержках, исключительных случаях и т.д. Тенденция такова, что ответственный реагирует «вдогонку» уже произошедшим событиям –задержкам или внешним сигналам, например, звонкам заказчика или директора по продажам по поводу задержки отгрузки или звонкам от поставщика по поводу задержки платежа. BPM-системы передают работу от одного исполнителя к другому. Они могут распределять нагрузку между группами исполнителей. Они напоминают исполнителю, как только ему назначена работа, и предоставляют ему информацию о приоритете и сроке, в который она должна быть выполнена. Они также сигнализируют исполнителю о том, что задание не выполнено в отведенное для него время. BPM-системы могут извещать ответственного и инициировать эскалацию задания ответственному, если оно не выполнено. Ответственный может легко проследить движение каждого экземпляра процесса и выполнить корректирующие действия или заблаговременно упредить исключительную ситуацию. Подобная функциональность позволяет организациям исключать задержки и неэффективность, в итоге снижая себестоимость и увеличивая продажи. ERP системы сами по себе не обеспечивают такой функциональности. Даже те, у которых есть workflow, не могут предложить достаточно изощренного описания, контроля и мониторинга. BPM системы делают возможным управление сквозными процессами предприятия. Бизнес-процессы можно определить как серию шагов (транзакций) выполняемых с целью преобразования входов в выходы. Бизнес-процесс имеет дело с логикой потоков информации, логикой потоков управления и транзакционной логикой. Логика потоков управления определяет последовательность действий, логика потоков информации определяет входы и выходы информации, требуемой на каждом шаге, а транзакционная логика определяет что мы получим на выходе. Возьмем в качестве примера процесс «Заказ на закупку», который состоит из следующих шагов: оформление заявки продавцом в офисе; оформление документов на отгрузку работником склада; оформление счета бухгалтером. Этот процесс требует дополнительного кредитного контроля от продавца в офисе. Например, если заказ на закупку превышает кредитный лимит, то требуется специальное одобрение менеджера по продажам, прежде чем на складе выпишут отгрузочные документы. Менеджер по продажам, для того, чтобы принять решение, нуждается в информации о деталях заказа, кредитном лимите и кредитной истории прежде, чем он это решение примет. Как часть транзакции создания документа Заказ, продавец должен рассчитать стоимость заказа, исходя из продукта, количества, цены, скидок, и применяемых налогов и пошлин. Продавец также должен учитывать данные о наличии ассортимента, производственном графике и графике доставки. В процессе «Заказ на закупку» логика потоков управления определяет действие после шага Оформление заказа, которое может быть либо Оформление документа на отгрузку, либо Получение санкции менеджера по продажам, зависящей от результатов кредитного контроля. Информационная логика определяет, какая информация должна быть предоставлена и какая получена от менеджера по продажам. И транзакционная логика определяет стоимость заказа и время доставки или решение менеджера по продажам. Если процесс заказа на закупку требуется автоматизировать или оснастить ИТ, то транзакционную логику может держать в ERP-системе, а логику даты доставки – в SCM системе. Однако, если вся логика процесса (логика потоков управления + потоки информации + транзакции) встроена в ERP или SCM систему, тогда мозгам ИТ придется провести огромную разработку и приложить усилия к интеграции, расширяя workflow модуль ERP или SCM системы, чтобы он охватывал процесса в полном масштабе. Подобный подход можно рассматривать только в качестве однократного упражнения и не может быть рекомендован, если организация нацелена на управление бизнес-процессами в масштабах предприятия. BPM-системы, с другой стороны, позволяют пользователям легко построить логику потоков управления и информации. Таким образом, они предлагают слой автоматизации и управления процессами, независимый от информационных систем предприятия, таких как ERP, SCM или CRM. Это дает организациям возможность управлять сквозными процессами предприятия. Одним словом, и бизнесу, и ИТ BPM-системы приносят выгоду в деле автоматизации и управления бизнес-процессами в масштабах предприятия и от начала и до конца. Смена парадигмы. Те, кому приходилось переживать смену парадигм, наверняка распознали знакомый цикл: надежда – преувеличенные ожидания – негатив – сбалансированная оценка. В очередной раз лихие «ковбои»-вендоры разогревают энтузиазмом, на этот раз вокруг компонентной архитектуры, позволяющей при помощи стандартных веб-сервисов создавать ориентированные на процессы решения. «Приложение» фактически разбирается на части, пробирается сквозь множество унаследованных систем, чтобы в итоге превратиться в композитное. Под угрозой оказывается традиционный взгляд на ERP как на тоталитарную монолитную систему. Ковбои и владельцы ранчо вновь борются за жизненное пространство, ресурсы и влияние на умы. Надежды, которые порождает новая технология, проистекают из обещаний максимальной гибкости и возможности предоставлять бизнес-функциональность намного быстрее и без затрат, связанных с разработкой полновесных приложений. Они вызывают преувеличенные ожидания того, что сегодняшние монолитные ERP-решения каким-то образом постепенно погрузятся в черную яму устаревания и безвестности. Негатив возникает, как только последователи основанных на SOA композитных приложений «обнаруживают» необходимость заботиться об управляемости, безопасности, следовании регламентам и методологии, которые только и способны систематически гарантировать соответствие ожиданиям в части целостности и производительности. (Тут пригодятся и забор, и клеймо.) Вслед за негативом приходит взвешенная оценка. В начале этого года я был на серьезной ИТ-конференции, на которой руководитель крупной компании, занимающейся CMDB (Configuration Management Database), был в явном восторге от того, что он видит надвигающийся хаос. Он чувствует, что движение к компонентно-ориентированным композитным приложениям откроет «ящик Пандоры» с легионом своенравных основанных на веб-сервисах приложений. Плохо продуманные смешанные (mash-up) приложения – не слишком приятное зрелище, и он предвкушает, как его компания будет зарабатывать деньги, помогая наводить в этом порядок. Быть может он прав, но есть надежда, что не все так ужасно. Без сомнения тоталитарные ERP (Enterprise Resource Planning) системы вчерашнего дня не были нацелены на нужды быстро растущей глобальной экономики и на изменчивую и непостоянную, но компьютерно-грамотную рабочую силу и клиентскую базу. Ни один из тех, кто прошел через внедрение ERP для нужд управления персоналом, бухгалтерии или управления отношениями с заказчиками, в жизни не пожелал бы снова через это пройти. Монолитные компьютерные приложения, изменять которые под силу только программистам, обещают сделать все, но в конечном итоге превращаются в нечто застывшее, похороненное внутри бизнес-подразделения. И хотя они способны масштабироваться на тысячи пользователей и, как правило, надежны и безопасны, в то же время выясняется, что такой способ автоматизации бизнеса является препятствием для его роста. Без сомнения, стать ориентированным на потребителя и на процессное управление легче с компонентами, чем с фиксированными корпоративными приложениями, которые трудно модернизировать и изменять. В комбинации SOA (Service Oriented Architecture) и BPM (Business Process Management) многие видят возможность сделать резкий, революционный скачок через ERP. Даже тяжеловесы рынка корпоративных приложений, такие как Oracle и SAP, ставят на это и инвестируют в Fusion и NetWeaver, чтобы застолбить для себя в этом новом мире такое же место, что и в старом. На самом деле старый мир от нас никуда не уходит, и ERP останутся с нами еще на много лет. Будет накапливаться все больше ключевых навыков, удовлетворяющих стратегическую потребность в более быстром их изменении и усовершенствовании. В качестве примера, ведущий международный телекоммуникационный оператор агрессивно вырос за счет поглощений, выхода на новые рынки и территории. Но с появлением тысяч новых сотрудников высшее руководство не в состоянии определить, все ли они находятся под надлежащим контролям своих менеджеров. Один вариант решения – многолетний проект консолидации и интеграции всех различных HR-систем, другой – «обернуть» их все при помощи BPM, вычленив ключевую задачу управления человеческими ресурсами, и добиться гибкости в течение месяцев, а не бесконечных лет. Надо ли также заменять локальные системы расчета зарплаты и налогов? Не обязательно. У «ковбоев» SOA – собственные проблемы. Инновации и гибкость – это хорошо, но «стрельба от бедра» может привести к непредвиденным последствиям. Перспектива карьерных проблем из-за «стрельбы по своим» в загоне SOA способна охладить любой энтузиазм. Вот почему упор должен делаться на стратегическом сосуществовании, на дополнительном эффекте от сделанных ранее инвестиций, на адекватном управлении жизненным циклом компонент и на достижении как коллегиального консенсуса, так и нового уровня соответствия регламентирующим требованиям – причем за счет управления на уровне методологии, а не законодательных требований. Модели управления SOA – SOA Governance (см. определение Википедии: http://en.wikipedia.org/wiki/SOA_Governance) сейчас только зарождаются. Искушение просто применить традиционные модели управления ИТ к миру композитных приложений SOA очевидно не имеет смысла и работать не будет. Подход, вытекающий из потребности в привычном управлении жизненным циклом, способен заморозить непрерывные усовершенствования; вновь мы видим традиционный «водопад» (waterfall), который становится тормозом, делающим невозможной быструю адаптацию, ограничивающим инновации и сбивающим с толку участников. Одно из возможных решений – прямо у нас под носом. BPM сейчас признан в качестве необходимого элемента SOA стратегии. Используя BPM немного нестандартно, можно коротким путем прийти к приемлемому варианту управления SOA. Средствами BPM можно реализовать процесс, в рамках которого бизнес-заказчики будут формировать запросы на новые композитные приложения SOA. Но по-настоящему большие перспективы откроются, если BPM использовать для управления SOA, когда ИТ берет его в свои руки и использует для управления работами, измерения уровня сервиса, составления отчетов по соответствию ITIL, обработки исключений и инцидентов и настройки производительности SOA. Вне зависимости от того, создается композитное приложение внутри BPM-системы (не все они являются для этого идеальными средствами), «процесс» создания композитного приложения SOA поддается более эффективному контролю и управлению, чем традиционные приложения MVC (model-view-controller). BPM-системы с сильной интеграционной составляющей могут контролировать ESB (Enterprise Service Bus) и расширить базовые возможности обмена сообщениями, мониторинга производительности и транзакций, просмотра репозитария и UDDI-интеграции, добавляя к ним SLA (Service Level Agreements) и среду совместной работы, которая отслеживает на каком основании приложение было создано, какая польза для бизнеса от него ожидалась и окупилось ли оно, а также обеспечивает следование корпоративной политике, требованиям безопасности и регламентов. Использование для этих целей BPM имеет смысл даже там, где имеются традиционные системы мониторинга. Почему? Потому что если для управления ИТ процессами мы используем BPM систему, то мы тем самым реализуем принципы постоянного мониторинга и улучшения процессов, что критически важно с точки зрения управления. И этот подход выглядит более созвучным философии компонентных композитных приложений. Со временем, по мере того как практика управления SOA будет становится более зрелой, постоянно будет повышаться уровень доверия организации к своим собственным процессам. Дополнительный плюс заключается в том, что такой подход позволит добиться симбиоза между унаследованными ERP и нарождающимся SOA. С новым шерифом в лице BPM, в управление SOA будут введены полицейские процедуры; женщины и дети снова смогут спокойно гулять по улицам, а воюющие стороны должны будут держать свои руки на виду. |