Области применения

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

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

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

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

5.1. Реинжиниринг бизнес-процессов

На тему реинжиниринга бизнес-процессов было написано множество книг, некоторые из них перечислены в списке литературы в конце этой или предыдущих глав. Однако рассказы о подлинном опыте, напротив, редки. Почему так? Конечно, потому что сущность реинжиниринга бизнес-процессов — это «фундаментальное переосмысление и преобразование всей совокупности бизнес-процессов предприятия или его подразделения». И в качестве целевой установки выступают «резкие и устойчивые улучшения эффективности процесса в отношении качества, затрат и времени». Чем скорее предприятия позволяют себе увлечься такой целью, тем труднее дается им фундаментальное переосмысление, и прежде всего по части внедрения полностью преобразованных процессов. Это особенно верно тогда, когда из нового процесса — что как раз типично для реинжиниринга бизнес-процессов — также вытекает новая организационная структура. Практика обнаруживает, что реинжиниринг бизнес-процессов может быть успешным только в комбинации с эффективным управлением организационными изменениями. Это ясно показывает, что реинжиниринг бизнес-процессов нуждается не только в организационном рычаге при внедрении, но и в «полномасштабном» бюджете проекта. Таким образом, для предприятий, уже находящихся в экономическом кризисе, проводить реинжиниринг бизнес-процессов часто слишком поздно. Тем не менее данный подход встречает особый интерес в развивающихся экономиках, как, например, Ближний и Дальний Восток, а также некоторые восточноевропейские страны.

5.1.1. Движущие силы и внешние факторы влияния

Экономия на издержках в реинжиниринге бизнес-процессов (РБП) — это один из желаемых побочных эффектов, однако она не годится в качестве единственной движущей силы. Успешные РБП-проекты отличаются тем, что ими движет желание оптимального исполнения предпринимательского видения, которое декларируется в миссии (Mission Statement). Это верно, естественно, не только для частных компаний, но в такой же степени и для государственного сектора, для объединений, фондов и ассоциаций. Кстати, так же верно и высказывание, что РБП-проект, не исходящий из ясно сформулированной и открыто обсуждаемой миссии, обречен на провал. Миссия организации должна отражать «предназначение» организации, какой цели она служит, какие ответственные лица стоят за этим, какие клиенты обеспечиваются какими продуктами и услугами и какая польза для клиента из этого вытекает. Также становятся все более важными положения о том, какую ответственность берет на себя предприятие перед своими клиентами и деловыми партнерами, своими сотрудниками и, наконец, перед обществом и окружающей средой.

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

В центре рисунка находится примерная процедура РБП: исходя из миссии, определяются бизнес-цели, пригодные для измерения успеха реализации миссии. Миссия и цели затем задают рамки, в которых стратегии разрабатываются и внедряются с помощью бизнес-процессов и при поддержке ИТ-систем и организационных правил. Из рисунка ясно, что для каждого рассматриваемого предприятия необходимо принимать во внимание массу внешних факторов, причем глобальный контекст в настоящее время для большинства предприятий можно принимать как нечто само собой разумеющееся. Из внешних факторов вытекают как риски, так и возможности, которые, как показывает опыт, часто неразрывно связаны друг с другом. РБП-процедуры должны уделять особое внимание этой взаимосвязи, чтобы суметь оптимально использовать потенциал для достижения успеха.

5.1.2. Управление эффективностью бизнеса (Business Performance Management)

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

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

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

5.1.3. Реинжиниринг бизнес-процессов на основе модели

Реинжиниринг бизнес-процессов проникает глубоко в самое сердце предприятия. И обыкновенно преобразование затрагивает всю организацию, включая все рабочие места, потоки работ и бизнес-правила. В этом смысле РБП касается всех вовлеченных в исполнение бизнес-процесса сторон: всех без исключения сотрудников по всем иерархическим уровням, клиентов и деловых партнеров и, конечно же, владельцев. И именно этот факт делает РБП настолько трудным, это он препятствует формированию повсеместно применимой модели реализации РБП. Тем не менее на практике появились некоторые распространенные подходы, чье описание, однако, выходит за рамки данной книги. Важно только понимать значение моделей бизнес-процессов для РБП. Для этой цели на рис. 5.4 представлен набросок концептуального подхода к реинжинирингу бизнес-процессов на основе модели. Процесс приблизительно разделен на этапы: диагностика, анализ, разработка вариантов и внедрение.

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

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

Помимо этих очевидных преимуществ использования моделей в РБП-проектах, необходимо решить еще одну проблему, которая часто недооценивается, хотя на практике она иногда сводит все усилия по РБП к откровенному абсурду. Речь идет о той проблеме, что пользователю чрезвычайно тяжело расстаться со своими «старыми, обкатанными» процессами. В таких случаях не следует ожидать новых процессных идей или тем более процессных инноваций. Спасти ситуацию тут может только абстракция. Она должна сделать возможным обсуждение на уровне реальных бизнес-требований, при этом не выбрасывая за борт неиспользованными незаменимые практические знания. Модели бизнес-процессов в данном случае — наилучший выбор! Они позволяют абстрагироваться от деталей конкретных внедренных бизнес-процессов и делают возможной на предметном уровне быструю разработку и оценку различных альтернатив процесса. Значение моделей для качества коммуникации и документации уже было освещено во многих разделах данной книги.

5.1.4. Использование эталонных моделей

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

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

Эталонные модели для РБП в идеале должны быть ориентированы на конкретную отрасль или адаптированы к определенной прикладной области, так что они уже своим понятийным аппаратом задают единые рамки для понимания всеми вовлеченными в проект. И модели внутри своей прикладной области должны быть сильно обобщены, чтобы не слишком ограничивать их применимость. Теперь рассмотрим две широко распространенные эталонные модели — eTOM и SCOR, которые не раз сослужили хорошую службу в РБП-проектах по всему миру.

5.1.4.1. Структура бизнес-процессов eTOM®

TeleManagement Forum — международный консорциум провайдеров коммуникационных услуг и их поставщиков. В рамках инициативы расширенной карты процессов деятельности телекоммуникационной компании (Enhanced Telecom Operations Map®, сокращенно: eTOM®) TeleManagement Forum предоставляет поставщикам услуг в телекоммуникационной индустрии и их бизнес-партнерам всеобъемлющую структуру бизнес-процессов. Исходя из обзорного представления цепочки добавленной стоимости, eTOM в обобщенной форме описывает все бизнес-процессы поставщика коммуникационных услуг и детализирует их в зависимости от их важности и приоритета. Процессы разделены на три области: «Стратегия», «Инфраструктура и продукт», «Управление и функционирование предприятия». eTOM служит поставщикам услуг в первую очередь в качестве эталонной модели в проектах по реинжинирингу бизнес-процессов, но также и как нейтральный ориентир для моделей партнеров, альянсов и контрактной работы с другими провайдерами и поставщиками.

5.1.4.2. Эталонная модель операций цепочки поставок SCOR®

Не только в индустриальной среде цепочки поставок сегодня отличаются интеграцией разнообразнейших бизнес-партнеров, которые во многих случаях рассеяны по всему глобусу. Цепочки поставок по своей сути представляют собой в высокой степени совместные процессы, в проектировании которых в идеале принимают участие все вовлеченные партнеры по процессу. Это требует единообразной и легко понятной коммуникационной платформы. Supply Chain Council предлагает для этого проверенную эталонную модель процесса SCOR (сокращение от Supply Chain Operations Reference Model). Цель модели в том, чтобы дать в руки пользователям инструмент, который позволит им провести обсуждение, реинжиниринг и оптимизацию процессов управления цепочками поставок как внутри предприятия, так и с бизнес-партнерами.

5.2. Управление бизнес-процессами и СОА

По крайней мере с середины 90-х годов бизнес-процессы всегда в центре обсуждения, если речь идет о вопросах корпоративной стратегии и организации. Даже при внедрении стандартного прикладного программного обеспечения для бизнеса (например, SAP или приложения Oracle) использование моделей бизнес-процессов уже давно современный уровень развития (см. раздел 5.3). В индивидуальной разработке информационных систем их значение, напротив, всегда недооценивалось. Многочисленные проекты, провалившиеся из-за расплывчатых или отсутствующих формулировок бизнес-процессов, подтверждают истинность этого утверждения.

Но теперь с растущим распространением понятия сервис-ориентированной архитектуры — СОА (Service-Oriented Architecture, сокращенно: SOA) бизнес-процессы приобрели совершенно новое значение. Уже первые примеры применения СОА показали, что одна только производительная инфраструктура не является решением для процессно-ориентированного управления и выполнения веб-сервисов и приложений. Более важно сформировать бизнес-процессы, составляющие сердце СОА, последовательно в соответствии с требованиями подразделений. Только если процессы действительно отвечают требованиям бизнеса, их автоматизация также может дать оптимальные результаты. Из этих соображений целостное управление бизнес-процессами, с которым мы уже познакомились в разделе 2.5, тем временем давно опередило тему СОА по своей важности. И в настоящее время бесспорно, что анализ бизнес-процессов стоит в центре каждого стратегического, организационного и ИТ-проекта. Модели бизнес-процессов тогда выступают в качестве центральной точки отсчета для всех предметных спецификаций и образуют мост к конкретному внедрению в форме организационных и ИТ-решений.

5.2.1. Взаимодействие между бизнесом и ИТ

Все более и более широкое распространение сервис-ориентированных архитектур обусловлено требованиями бизнес-подразделений. ИТ должно реагировать на новые корпоративные стратегии, которые настроены на изменения и в любой момент быстро адаптируются к будущему развитию. Руководство предприятия по праву требует бизнес-процессных решений и платформ информационных систем, которые позволяют экономичное и прежде всего быстрое внедрение такого рода стратегий. Частью внедрения неизменно будет бесшовная интеграция приложений и веб-сервисов по всем цепочкам процессов. Можно ли как-то достичь требуемой при этом гибкости интеграции без раздувания затрат на проект? И как-то принять в расчет разнородность приложений и сервисов и застраховать уже сделанные инвестиции в ландшафт прикладных систем? Ответы на эти вопросы обещает сервис-ориентированная архитектура (СОА) в контексте целостного управления бизнес-процессами.

Рис. 5.5 обобщает эти соображения на схеме. Исходя из миссии компании производятся стратегические рассуждения, в конечном счете выливающиеся в организационные процессы и структуры, которые воплощаются в соответствующей инфраструктуре. Показано взаимовлияние, которое оказывает бизнес-обусловленная деятельность на ИТ. ИТ-стратегия происходит из бизнес-стратегии и учитывает при этом текущее состояние информационных и коммуникационных технологий. На основании этого — с учетом организационной концепции — разрабатываются бизнес-процессы и бизнес-сервисы, которые на базе сервис-ориентированной ИТ-инфраструктуры и внедренных затем ИТ-сервисов (веб-сервисы и приложения) предоставляются в распоряжение бизнес-подразделения в качестве ИТ-сервисов. «Обещание» СОА бизнес-подразделениям гласит тогда: обеспечить быстрое реагирование на новые бизнес-требования при оптимальном удобстве использования и экономичности.

5.2.2. Внедрение СОА на основе моделей

Для СОА не существует повсеместно применимого определения. Поэтому на практике совершенно по-разному построенные системные архитектуры часто именуются как сервис-ориентированная архитектура. Откровенно говоря, мы также не придаем слишком большого значения этому термину, скорее, мы рассматриваем его с точки зрения целостного управления бизнес-процессами. Это предусматривает в идеале внедрение в форме веб-сервисов и прикладных блоков, оркестрированных в максимально возможно автоматизированные процессы. На рис. 5.6 показан пример СОА, как она реализована в одной компании из электронной индустрии. Это предприятие обслуживает как бизнес, так и частных клиентов. Для этого в распоряжение предоставляются ориентированные на целевую группу веб-порталы: бизнес для бизнеса (B2B) и бизнес для клиента (B2C), — каждый из которых также включает функциональность электронного магазина.

Основу представленной СОА формирует «Сервисная шина предприятия» (Enterprise Service Bus, ESB), которая отвечает за интеграцию на уровне данных. Она обеспечивает открытую, легко адаптируемую интеграционную платформу, которая поддерживает технологии и протоколы для подключения различных систем. Обмен сообщениями может быть на выбор синхронным либо асинхронным. К диапазону функций относятся всевозможные механизмы для преобразования данных через XSLT и для семантического сопоставления бизнес-объектов между системами. Сервисная шина предприятия также берет на себя безопасную маршрутизацию данных между исходными и целевыми системами.

В этом примере интернет-соединения с внешними партнерами по процессу, так же как и соединение бизнес-приложений и хранилища данных, реализуется непосредственно через сервисную шину. Интернет-порталы и расположенный во внутренней сети корпоративный портал («бизнес для работника» — Busines-to-Employee/B2E), через который сотрудникам предприятия предлагаются важные для них функции управления бизнесом, а также совместной работы и управления знаниями, интегрируются посредством процессов BPEL. Такая концепция обладает тем преимуществом, что в процессах BPEL полная логика процесса может в гибкой манере сохраняться и затем оцениваться во время исполнения. Изощренная функциональность мониторинга делает возможным на основе ключевых показателей непрерывное совершенствование процесса.

Не только в процессах BPEL, но также и в маршрутизации пакетов данных ESB и в осуществляемых пользовательских функциях выражаются процессы. Все без исключения компоненты СОА только тогда могут выполнить бизнес-требования, когда они «скроены» под затрагиваемые ими бизнес-процессы. Это еще раз подчеркивает важность целостного управления бизнес-процессами: модели формируют базовую структуру любого профессионально продуманного решения СОА. В легко понятной графической форме модели отображают конструктивный план СОА, в котором они описывают лежащие в основе бизнес-процессы и бизнес-сервисы (см. раздел 5.3). Благодаря абстрагированию от деталей технической реализации они обеспечивают прозрачность и становятся наиболее важной средой коммуникации, когда речь идет о вопросах бизнеса. Таким образом, ИТ-специалистам впервые содействуют эмансипированные руководители и бизнес-эксперты, которые могут сформулировать свои требования четко и наглядно. Результатом являются понятно задокументированные бизнес-процессы, которые формируют хорошую основу для внедрения в СОА и впоследствии достигают высокого уровня принятия в повседневном использовании.

5.2.3. Эталонные модели и модели передового опыта для СОА

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

Для моделирования процедур в бизнес-процессах на всех уровнях используются XML-сети. Применение формального языка позволяет избежать неоднозначности в описаниях процессов и функций. Сервис-ориентированное структурирование на базе инкапсулированных сервисов обеспечивает прозрачность в отношении лежащих в основе ИТ-систем. Модели бизнес-процессов должны учитывать концепции сервис-ориентированной архитектуры, так чтобы оркестровка сложных процессов была возможна из существующих сервисов на разных уровнях. Чтобы справиться со сложностью, строится многослойная иерархия процессов на четырех уровнях, представленных в разделе 4.6. Такая глубина детализации показала себя в практических проектах как вполне наглядная. В зависимости от масштаба проекта количество слоев может соответственно корректироваться. Описание процессов начинается с общепонятных операционных бизнес-процессов на верхних уровнях абстракции и затем конкретизируется на нижних подробных уровнях с уже существующими или только предстоящими к реализации техническими сервисами.

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

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

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

Рис. 5.7 показывает реализацию таких подробных уровней с помощью сетей XML. На основе обогащения дополнительной информацией о лежащих в основе технических веб-сервисах они затем могут быть преобразованы специальными алгоритмами в BPEL, так что смоделированные бизнес-процессы могут исполняться в СОА. В таких расширенных сетях XML должно быть ровно одно хранилище объектов без входящей связи. Такое хранилище объектов представляет собой вход для XML-сети. Точно так же существует ровно одно хранилище объектов без выходной связи. Такое хранилище объектов аналогично представляет собой выход для сети. XML-схемы входных и выходных хранилищ объектов указывают, какие сообщения BPEL-процесс ожидает к началу и какие отправляет по завершении. XML-схемы хранилищ объектов в областях до и после действий, которые находятся между входным и выходным хранилищами объектов, понимаются как схемы сообщений, которые посылаются соответствующему веб-сервису либо возвращаются назад к BPEL-процессу. Дополнительно требуемые в сравнении с чистыми XML-сетями данные, которые должны вноситься для преобразования в BPEL, назначаются действиям. Если необходимо привязать веб-сервис к действию, тогда его WSDL-файл должен иметься в наличии и быть соответственно назначен. Язык описания веб-сервисов (Web Service Description Language, WSDL) используется для независимого от платформ описания сервисов СОА на базе веб-сервисов. WSDL — это основанный на XML язык для описания веб-сервисов и их интерфейсов. В описании веб-сервиса должны быть указаны его функциональность и информация относительно его вызова и использования. На основе файла WSDL для действия должны быть выбраны дальнейшие атрибуты, как, например, выбор соответствующей операции веб-сервиса для текущего шага процесса. Кроме того, должен быть установлен тип соответствующего базового действия. Это дает информацию, какое базовое действие BPEL отображает этот переход. Можно установить следующие типы действия: receive, reply, invoke, empty или wait.

Для исполнения процессов могут также применяться всеобъемлющие интеграционные архитектуры, как, например, Oracle Application Integration Architecture (Oracle AIA), которая использует BPEL в качестве технологии исполнения процесса. Поскольку описание процедур в сетях Петри или XML-сетях принципиально не зависит от технологии, для описания процессов с учетом соответствующих технических аспектов можно использовать алгоритмы генерирования и для других технологий исполнения.

5.3. Процессно-ориентированное внедрение бизнес-приложений

При внедрении конфигурируемого программного обеспечения для бизнеса, как, например, SAP, приложения Oracle, Microsoft Dynamics или 1С: Предприятия, также все больше и больше применяются концепции и технологии СОА. Для определения и реализации таких систем программного обеспечения требуются подходы на основе моделей. Реализованная в методе Horus концепция абстрактного внедрения бизнес-процессов на базе бизнес-сервисов (см. раздел 4.5) особенно хорошо подходит для этой цели. К тому же эталонные модели с предопределенными бизнес-процессами, как это предусматривает метод Horus, именно со стандартным программным обеспечением могут значительно ускорить внедрение и существенно улучшить качество полученных результатов.

5.3.1. Почему так сложно внедрять бизнес-приложения

Существует множество историй о провалившихся или по крайней мере сильно затянувшихся и взлетевших по затратам софтверных проектах. Значительная часть таких проектов занималась внедрением стандартного ПО, хотя на первый взгляд это и казалось легче, чем индивидуальная разработка нового ПО. Почему проекты внедрения бизнес-приложений сложнее, чем кажется, будет объяснено в дальнейшем, чтобы вывести из этого усовершенствованный подход.

Часто уже в ходе внедрения бизнес-приложений впервые выясняется, что бизнес-процессы стандартного ПО не подходят для текущих процессов предприятия. Обширная функциональность стандартного ПО и вытекающая из этого сложность приводят к разветвленному пониманию термина «стандарт» в отношении процессов. Разнородные ландшафты ИТ-систем — другой источник проблем при внедрении стандартного ПО. Сложные интерфейсные решения для интеграции различных систем требуют дополнительно больших усилий. Что касается затрат на внедрение, ожидается — часто ошибочно, — что стандартное ПО явно дешевле, чем сравнимая индивидуальная разработка. Для этого стандартное ПО в большинстве случаев предлагает возможность создания программного решения из модулей, которые также могут приобретаться по отдельности. Это опять же выдвигает повышенные требования к гибкости внедренческого подхода.

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

Для бизнес-пользователей внедрение нового бизнес-приложения всегда испытание, поскольку, во-первых, требует совершенно других навыков, чем повседневная деятельность, и, во-вторых, работа по проекту часто должна выполняться еще в дополнение к стандартным задачам. Обучение новому бизнес-приложению тяжело, поскольку из-за сложности ПО документация тоже, соответственно, объемная. Кроме того, реальная ценность таких решений часто видима только в реализованной благодаря внедренному ПО сыгранности нескольких подразделений компании. Такой всеобъемлющий взгляд на решение остается, однако, скрытым от многих пользователей. Эта же проблема часто обнаруживается и в системной документации, поскольку она ориентирована чисто на функционал, а отнюдь не на процесс. Эти перечисленные пункты приводят в целом к более длительному выполнению проекта и нередко к перерасходам бюджета. Более того, функции, не охваченные стандартным ПО, часто выявляются только при тестировании системы.

5.3.2. Управляемый моделями, сервис-ориентированный подход к внедрению

От многих из описанных проблем мир не получится избавить традиционными подходами к внедрению бизнес-приложений, и, следовательно, требуются новые подходы. До сих пор внедрение бизнес-приложений имело место в рамках классического программного инжиниринга, начиная с анализа требований и заканчивая вводом системы в эксплуатацию. Моделирование внедряемых бизнес-процессов в рамках анализа требований подготавливает базу для проектирования и создания архитектуры системы. Проблематика такого подхода при внедрении стандартного ПО заключается в отклонении специфических бизнес-процессов предприятия от заданных процессов стандартного прикладного ПО. Создание многослойной модели делает возможным в зависимости от степени абстракции представление бизнес-сервисов, то есть функциональности бизнес-приложения, на различных уровнях. Модели бизнес-процессов в сочетании с моделями бизнес-сервисов, по замыслу метода Horus, уменьшают сложность и позволяют гибко управлять бизнес-процессами предприятия через оркестровку бизнес-сервисов. Они могут горизонтально комбинироваться в «сквозные» бизнес-процессы или вертикально связываться друг с другом через декомпозицию. Внедрение этих процессов может происходить на основе стандарта BPEL (см. раздел 5.2), который во многих бизнес-приложениях уже используется для системной интеграции.

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

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

5.3.3. Практическое применение эталонной модели бизнес-сервисов

Представленный внедренческий подход имеет условием наличие эталонных моделей, которые удовлетворяют описанным в разделе 4.6 требованиям метода Horus. В дальнейшем иллюстрационно будет рассмотрена выдержка из эталонной модели бизнес-сервисов, которая определяет композитный бизнес-сервис «Заказ –> Оплата» (Order2Cash). Внедрение этого сервиса с использованием приложений Oracle (здесь — Oracle E-Business Suite, сокращенно: EBS) уже было реализовано в нескольких проектах на основе модулей Oracle «Управление заказами», «Дебиторская задолженность», «Управление денежными средствами» и «Главная книга».

Представленный на рис. 5.8 оркестрованный процесс Уровня 0 иллюстрирует взаимодействие различных бизнес-сервисов для процесса «Заказ –> Оплата». Основной процесс описывает процедуру от размещения вплоть до поступления платежа для соответствующего заказа. Однако оркестрованный процесс содержит, помимо этого, также бизнес-сервисы со стороны закупок, поскольку они необходимы для заказов, которые должны быть обработаны как транзитные поставки. Здесь в таком случае также дополнительно необходимы модули Oracle «iProcurement», «Закупка» и «Кредиторская задолженность».

Представленный на рис. 5.8 Уровень 1 показывает укрупненный процесс внутри основного бизнес-сервиса «Заказ –> Доставка» (Oder2Shipment). Шаги в представленной укрупненной процедуре являются компонентами процесса, которые необходимы для выполнения заказа. Использование имен существительных и общепринятых бизнес-управленческих терминов в наименованиях шагов показывает высокую степень абстракции на данном уровне. Однако здесь уже следует учитывать различные процедуры в зависимости от конкретного бизнес-сценария, то есть заказы на услуги, заказы на склад и производственные заказы обрабатываются по-разному.

Рис. 5.9 показывает в верхней части подробную процедуру внутри компоненты процесса «Отгрузка товара» бизнес-сервиса «Заказ –> Доставка». По сравнению со структурой эталонной модели в разделе 4.6.2 ясно видно, что в данной модели Уровень 2 был опущен. Здесь каждому действию уже назначена роль. Например, товарная накладная создается работником склада, а заключительное подтверждение доставки выполняется руководителем склада. Действиям, которые выполняются автоматически, назначается роль «Система». Кроме того, здесь также могут быть назначены действиям отдельные функции (сервисы) EBS. При привязке между действием и функцией описывается конкретное применение в ходе процесса. Альтернативно можно определить новые функции, которые в таком случае дополнительно должны быть реализованы в рамках внедрения.

Нижняя часть рис. 5.9 изображает пользовательскую инструкцию «Выполнение отправки». Здесь для роли «Рабочий склада» определяется, как выполняется отправка с использованием соответствующей функции Oracle EBS. Также здесь можно назначить действиям, то есть в данном случае шагам инструкции, отдельные функции EBS или, если таковых не имеется, дополнительно задать.

5.3.4. Миграция бизнес-приложения

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

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

В преддверии миграции для процесса закупок был идентифицирован наибольший потенциал оптимизации. Так, в качестве первого шага был начат проект реинжиниринга для кросс-функционального процесса закупок. Этот процесс затрагивает помимо собственно закупок также и области приемки заказов, подготовки изделия, управления поставщиками и проверки счетов.

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

5.3.4.1. Анализ «как есть»

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

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

5.3.4.2. Анализ «как должно быть»

На основе выработанной структуры процесса и задокументированных проблем и открытых вопросов из анализа «как есть» была разработана модель «как должно быть». После обсуждения с каждым из ответственных сотрудников процессы были усовершенствованы. Подробные процессы обсуждались и усовершенствовались внутри бизнес-подразделений, в то время как обсуждение и усовершенствование кросс-функционального взаимодействия подразделений шло в более широких рамках. Рис. 5.11 изображает оптимизированный основной процесс «Закупки», который теперь отвечает всем требованиям, вытекающим из модели «как есть». Это, с одной стороны, конкретные процедуры с четкими зонами ответственности для бывших до сих пор неясными подпроцессов или шагов. С другой стороны, на детальном уровне также уже отражены требования по технической реализации через ИТ, которые должны быть реализованы при миграции на новый релиз Oracle E-Business Suite путем соответствующей конфигурации доступной стандартной функциональности, через настройку специальных потоков работ или через дополнительную функциональность.

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

5.3.4.3. Итог

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

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

5.4. Регулирование, управление рисками и соблюдение норм (GRC)

Времена, когда предприятием можно было управлять исключительно «по воле помещика», уже давно прошли. На стремительный рост по всему земному шару экономической, экологической и компьютерной преступности контролирующие органы реагируют все более и более сложными правилами работы. Суть в том, что для предприятия, работающего по всему миру, более недостаточно соблюдения только национальных норм по месту нахождения штаб-квартиры предприятия, но необходимо соблюдать всю совокупность правил, которые затрагиваются в рамках транснациональных бизнес-процессов. Такие правила в немалом количестве случаев даже несовместимы друг с другом. Для этого инвесторам и финансовым институтам требуется эффективная система управления рисками, например посредством организации систем раннего оповещения для распознавания рисков и для обеспечения большей прозрачности внутри финансового процесса. Ключевые слова здесь — SOXи Базель II. Кроме того, все более сокращающемуся «периоду полураспада» стратегических решений можно противостоять только с помощью эффективно управляемых и надежных бизнес-процессов. Короче говоря: темы регулирования, управления рисками и соответствия нормам (Governance, Risk Management and Comlinance, сокращенно: GRC) в повестке дня менеджмента стоят на самом верху; эти темы очерчивают одну из самых важных прикладных областей для инжиниринга бизнес-процессов. Польза от всеобъемлющих моделей бизнес-процессов с применением GRC особенно велика, поскольку большинство требований относится к качеству управления процессом и прозрачности бизнес-операций. Но сначала краткое пояснение понятий.

• Регулирование (Governance) — это управление предприятием на основе ясно и понятно сформулированных бизнес-целей и инструкций. Важные условия здесь — согласованность с правовыми нормами и полнота. Регулирование проходит сквозь все подразделения и уровни предприятия, почему мы и говорим о горизонтальном и вертикальном регулировании.
• Управление рисками (Risk Management) означает совокупность всех мер для обращения с известными и неизвестными внутренними и внешними рисками предприятия. Сюда относятся организация систем раннего оповещения для распознавания рисков, а также меры по устранению самих возможностей рисков и по исправлению последствий наступивших рисков.
• Соответствие нормам (Compliance) означает выполнение, соответствие или согласованность с государственными законами, как и с правилами и спецификациями, с (этическими и моральными) принципами и процедурами, а также со стандартами (например, ИСО) и соглашениями, которые четко определены. Выполнение соответствия нормам может быть основано как на принуждении (например, через закон), так и на доброй воле (например, следование стандартам).

5.4.1. Факторы влияния и механизмы GRC

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

Рис. 5.12 показывает типичную структуру концепции GRC. Кажется подавляющим многообразие внешних требований, за принятие во внимание и соблюдение которых корпоративный менеджмент назначен ответственным и во многих случаях также лично ручается. Задача руководства в том, чтобы сформулировать надлежащие руководства к действию, довести их до сведения и следить за их соблюдением. Даже больше: руководства к действию должны быть полными, эффективными и действенными, а также не противоречащими сами себе. Далее необходимо внедрить механизмы, которые управляют и контролируют выполнение инструкций. К тому же надо предусмотреть механизмы реагирования, которые заботятся о том, чтобы предприятие при угрозе или факте нарушения регламентов незамедлительно приняло надлежащие меры для ограничения ущерба для окружающей среды и самого предприятия. Осознающие свою ответственность предприятия уделяют наибольшее внимание превентивным механизмам. Потому что в стремлении избегать рисков и нарушения норм лежит ключ к значительной экономии на издержках и к прозорливому поведению на рынке, впоследствии нередко приводящим к интересным конкурентным преимуществам.

Однако, как видно из этих соображений, выработка и последующая реализация всеохватывающей концепции GRC проявляет высокую степень сложности. Действительно управляемой она будет, только если взаимосвязи предприятия будут отображены в согласованной модели. На основе этой модели становятся возможны анализ и оптимизация, а также разработка работоспособной системы GRC. В связи с этим GRC представляет собой одну из самых важных областей применения метода и инструментария Horus.

5.4.2. Реализация GRC в контексте предприятия

В преддверии введения GRC на предприятии часто обсуждается вопрос, является ли это бизнес-проектом или же ИТ-проектом. «Как одно, так и другое» должен здесь звучать правильный ответ. Взгляд на рис. 5.13 ясно это показывает: GRC всегда лежит в зоне ответственности руководства предприятия и поэтому всегда стратегический проект. GRC проникает далее вглубь предприятия и пронизывает его тем, что реализуются механизмы, которые воздействуют на все уровни — от стратегии через бизнес-процессы и прикладное программное обеспечение до ИТ-платформы.

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

GRC часто структурируется в три комплекса мероприятий, которые отражают различные точки зрения на GRC, однако тесно связаны между собой.

• GRC в финансах и аудите.

  SOX, Базель II, специфические для каждой страны принципы надлежащего бухгалтерского учета и т.п. служат движущими силами GRC в сфере финансов и аудита. Требуется плотная совместная работа с аудиторами и финансовыми и налоговыми органами. Системы внутреннего контроля должны обеспечивать корректное и соответствующее правилам исполнение процессов в финансовом и бухгалтерском учете. Особое значение представляет мониторинг бизнес-операций на основе показателей, относящихся к эффективности предприятия (ключевой показатель эффективности, KPI) и рискам (ключевой индикатор риска, KRI).

• GRC в правовых вопросах и процессах.

  Этот вид GRC ставит в центр внимания операционный бизнес. Соблюдены ли все юридические требования? Выяснены ли таможенные и налоговые вопросы? Гарантируют ли бизнес-процессы соблюдение норм (например, ИСО, DIN) и стандартов (включая отраслевые стандарты) за пределами национальных границ? Кроме того, должны быть приняты во внимание рыночные риски и опасности из-за прекращения работы (например, из-за форс-мажора).

• GRC в ИТ.

  Информационные технологии в GRC не только играют важную роль при внедрении GRC-механизмов — подумайте об автоматизации бизнес-процессов и мониторинге ключевых показателей, — но также скрывают в себе значительные потенциальные риски. И они подчиняются многочисленным регламентам, например в отношении защиты данных (федеральный закон о защите информации). Посредством надлежащих мер следует обеспечить безопасное и соответствующее законам обращение со всеми без исключения информационными ресурсами. Кроме того, необходимо предотвращать программные и технические аномалии и нарушения действующих положений, например относительно разделения обязанностей (SoD, Segregation of Duties).

5.4.3. Предотвращение «лоскутной информатизации»

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

Что касается разнообразия бизнес-требований, Horus обладает тем преимуществом, что созданные подмодели могут быть формально связаны друг с другом, как представлено на рис. 5.14. Такого рода интегрированная модель предприятия препятствует тому, чтобы для GRC создавались новые «информационные заплатки», ведущие к неэффективности и, таким образом, стоящие на пути захватывающих возможностей оптимизации.

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

Этот пример еще раз подчеркивает пользу от работы с формальными моделями предприятия. Рис. 5.15 иллюстративно показывает выдержку из модели, которая была применена в рамках GRC-проекта в сфере финансов и аудита. Она разработана на основе базы знаний бизнес-сервисов Horus. Показаны процедуры из бухгалтерского учета, в особенности сверка главной книги и интеграция ее результатов в работы по закрытию месяца.

5.5. Управляемые сервисы и библиотека инфраструктуры информационных технологий (ITIL)

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

5.5.1. Аутсорсинг в сравнении с управляемыми сервисами

Многие компании реагируют на эти вопросы стратегиями аутсорсинга, диапазон которых может варьироваться от аутсорсинга инфраструктуры вплоть до полного аутсорсинга систем и приложений. Однако сложные и долгосрочные аутсорсинговые контракты нередко неприемлемо ограничивают способность предприятия к реагированию. И о том, что выпустили из рук ответственность за персонал, инфраструктуру и операционные цели ИТ, многие клиенты аутсорсинга задним числом горько сожалели, самое позднее тогда, когда они через инсорсинг ценой больших усилий протаптывали обратную дорожку. Элегантную альтернативу представляют собой управляемые сервисы (Managed Services), которые, впрочем, в конечном счете воплощают специальную форму аутсорсинга: ответственность первоначально остается за заказчиком, который в полном соответствии с собственными пожеланиями частично передает ее на время поставщику услуг. Таким способом заказчик может сконцентрироваться на своих ключевых компетенциях и в соответствии со своими текущими задачами приобретать дополнительные компетенции, специальные ноу-хау и доступ к новым технологиям. Это приводит к улучшению способности реагировать на новые бизнес-требования и к тому же к более высокому уровню сервиса — и это при возрастающей эффективности и снижающихся затратах.

5.5.2. Структурирование решения

Для обоих вариантов — аутсорсинга и управляемых сервисов — важно детально и непротиворечиво определить уровни сервиса. В качестве основы для такого описания зарекомендовало себя изображение ИТ-ландшафта, относящегося к сервисам, в виде унифицированной структуры. Благодаря этому становятся сопоставимыми соглашения об уровне сервиса (Service Level Agreements) и можно определить измеримые критерии качества и эффективности. В остальном доказало свою эффективность измерение ключевых показателей до и после выполнения аутсорсинговых мероприятий, чтобы таким образом получить объективную основу для оценки успеха. Особенно в англосаксонской среде все больше и больше преобладает так называемое ценообразование на основе ценности (Value-based Pricing), при котором часть сервисного вознаграждения оценивается в зависимости от полученной добавленной стоимости.

В контексте метода Horus для структурирования ИТ-ландшафта хорошо зарекомендовала себя четырехуровневая модель, представленная на рис. 5.16. Основу модели формирует ИТ-платформа с ее аппаратными, коммуникационными и программными (системное ПО) компонентами. Над ним стоит Прикладное программное обеспечение, которое собирается из, возможно, разнородных модулей, соединенных между собой с помощью подходящих механизмов интеграции. Опираясь на это, определяются и при необходимости затем документируются бизнес-процессы и стратегии. Особенность заключается в том, что четырехуровневая модель также простирается за корпоративные границы, так что даже виртуальные единицы могут быть отображены.

Управляемые сервисы затем последовательно выстраиваются по этой четырехуровневой модели, так чтобы на каждом уровне предлагались точно для этого предназначенные сервисы. Это увеличивает эффективность сервисов и открывает потенциал для устойчивого сокращения затрат. Управляемыми сервисами можно воспользоваться на всех этапах жизненного цикла ИТ-ландшафта или ИТ-решения — и это через все уровни четырехуровневой модели. Какую поддержку и в каком объеме он хотел бы привлечь, сервис-клиент сам решает согласно своим потребностям и бюджету. Портфель управляемых сервисов распространяется на все этапы внедрения ИТ-решения: от первой идеи проекта через прототипирование вплоть до разработки и запуска. Он охватывает и эксплуатацию, включая мониторинг, администрирование и непрерывную оптимизацию решения. К концу жизненного цикла, как только меры по оптимизации начинают давать лишь незначительный эффект или исходя из стратегических соображений, происходит реинжиниринг ИТ-решения. Это может быть просто реинжиниринг технической инфраструктуры или прикладного ПО, а может — и подлинный бизнес-реинжиниринг на уровне бизнес-процессов или стратегии. Здесь также предлагаются соответствующие сервисы, например проведение имитационных исследований.

Вероятно, наибольший потенциал сокращения затрат от эксплуатации ИТ-решений таится, как показывает опыт, во внедрении методов самообслуживания (Self-Service) в поддержку пользователей. При этом стоит заметить, что с помощью этих методов можно добиться не только устойчивого снижения затрат, но наряду с этим также улучшенного качества сервиса — например, путем создания службы поддержки 24/7. Чтобы пользователь также это воспринял, важно, чтобы методы самообслуживания были легкодоступны и полезны и — по крайней мере на переходном этапе — соединены с традиционными каналами поддержки. Методы самообслуживания на практике, как правило, внедряются на базе веб-порталов, которые располагаются во внутренней сети или интернете. Веб-порталы в таком случае предоставляют в распоряжение разнообразные функции управления сервисами и знаниями и посредством онлайн-форумов и чатов дают возможность формирования сообществ по интересам. При необходимости сюда также могут быть интегрированы интерактивные тренинг-системы и средства обучения.

5.5.3. ITIL — спецификация сервисов на основе эталонной модели

Обеспечение клиентоориентированности ИТ-сервисов обобщается термином Управление ИТ-сервисами (IT-Service Management). Управление ИТ-сервисами охватывает все стандартизированные, а также зарекомендовавшие себя в бизнес-практике методы поставщика услуг для обеспечения клиентоориентированных ИТ-сервисов. На протяжении своего жизненного цикла ИТ-сервисы с учетом внешних и внутренних факторов влияния систематически планируются, разрабатываются, предоставляются, измеряются, управляются и непрерывно улучшаются. ИТ-сервис необходим для исполнения полуавтоматизированных или автоматизированных действий в бизнес-процессах и является конечным результатом ИТ-сервисного процесса. ИТ-сервисный процесс посредством вовлечения ИТ-сервисных компонентов обеспечивает удовлетворительные характеристики с целью поддержки бизнес-процесса получателя сервиса в соответствии с договором. Внедрение стандартизированных ИТ-сервисных процессов, например с применением Библиотеки инфраструктуры ИТ (ITIL), а также разработка стандартизированных ИТ-сервисов поставщиком услуг должны облегчить более быстрое и более гибкое отображение в ИТ-сервисном процессе требований клиентов относительно ИТ-поддержки их бизнес-процессов.

Структура ITIL — это всемирно устоявшийся стандарт де-факто для управления ИТ-сервисами. ITIL предлагает, что должно быть сделано для управления ИТ-сервисами, но не то, как предложенные методы реализуются в конкретном случае. Способ реализации остается на усмотрение каждого предприятия. Текущая третья версия ITIL состоит из компонентов ядро ITIL (ITIL Core — руководство для всех организаций, предлагающих IT-сервисы) и дополнительные рекомендации ITIL (ITIL Complementary Guidance — руководство для специфических отраслей промышленности, типов организаций, операционных моделей и технических архитектур).

Ядро ITIL в качестве важнейшего руководства для бизнес-практики включает следующие книги: «Стратегия сервиса» (англ. Service Strategy), «Проектирование сервиса» (англ. Service Design), «Передача сервиса» (англ. Service Transition), «Эксплуатация сервиса» (англ. Service Operation) и «Постоянное улучшение сервиса» (англ. Continual Service Improvement). Вместе эти издания отражают этапы жизненного цикла ИТ-сервиса. Помимо этого, описываются стратегии проектирования и обеспечения ИТ-сервисов, а также методы передачи ИТ-сервисов в эксплуатацию. В дополнение задается генеральная линия для организации процесса непрерывного улучшения. Целью жизненного цикла ИТ-сервиса является поддержка непрерывного обучения, улучшения и «созревания» организации. Стратегия обеспечения ИТ-сервисов стоит в центре жизненного цикла. Этап «Стратегия сервиса» описывает лежащее в основе понимание информационных технологий как стратегического актива, в котором предлагается руководство, как следует проектировать, разрабатывать и внедрять управление ИТ-сервисами не только с организационной, но и со стратегической точки зрения. В рамках этапа «Проектирование сервиса» предоставляется руководство по проектированию и разработке ИТ-сервисов и процессов их управления. Реализация требований для новых или измененных ИТ-сервисов из «Стратегии сервиса» рассматривается на этапе «Передача сервиса». Управление ИТ-сервисами и их эксплуатация происходят на этапе «Эксплуатация сервиса». Непрерывный процесс улучшений охватывает весь жизненный цикл ИТ-сервиса в рамках «Постоянного улучшения сервиса». Поставщик услуг должен реализовать последовательные и повторяемые ИТ-сервисные процессы, чтобы иметь возможность поддерживать или улучшать качество ИТ-сервиса.

Недостаток ITIL, однако, заключается в неформальном представлении предложенных ИТ-сервисных процессов. Чтобы можно было выполнить качественный и количественный анализ, необходимо формальное моделирование ИТ-сервисных процессов. Для тщательного, графического моделирования таких процессов подходят типы моделей, рекомендуемые методом Horus. Центральную точку отсчета формируют процедурные модели в форме сетей Петри (рис. 5.17).

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

5.6. Аутсорсинг бизнес-процессов

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

Перемещение бизнес-процессов как часть стратегии виртуализации называется аутсорсингом бизнес-процессов (Business Process Outsorsing, сокращенно BPO). Посредством BPO полное исполнение какого-то бизнес-процесса, включая все лежащие в основе бизнес-сервисы, поручается поставщику услуг BPO. Часто с помощью BPO стремятся к преимуществам по затратам, прежде всего если речь идет о персонало- или ресурсоемких процессах. Однако следует предостеречь от того, чтобы расценивать BPO только с точки зрения затрат. Гораздо важнее принимать решение об аутсорсинге бизнес-процессов с точки зрения добавленной стоимости. Необходимо рассмотреть преимущества при освоении новых рынков (например, посредством привлечения локального партнера-дистрибьютора на целевом рынке) или использования специализированных знаний (например, посредством специализированных производственных процессов, которые привносит в цепочку создания ценности стратегический производственный партнер). Также сокращение времени процессного цикла или минимизация процессных рисков — веские аргументы при решении в пользу аутсорсинга бизнес-процессов.

5.6.1. Типичные области применения

Далее мы обратимся к некоторым важным для практики прикладным областям для аутсорсинга бизнес-процессов.

5.6.1.1. Персоналоемкая обработка транзакций

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

— Финансовые услуги.

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

— Торговля.

Логистика, грузовые накладные, управление заказами, возвраты, выверка счетов.

— Страхование.

Котировки, заключение контрактов, расчет премий, дебиторская задолженность, обработка страховых требований.

— Здравоохранение.

Расчет страховых взносов, обработка требований на возмещение, дебиторская задолженность, отклоненные требования на возмещение.

5.6.1.2. Наукоемкие процессы

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

— Производство OEM.

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

— Контрактная логистика.

Зафиксированный в договоре пакет логистических услуг (транспортировка, складирование, обработка и т.д.), который предоставляется поставщиком логистических услуг для закупочных или сбытовых организаций.

— Дистрибьюторские услуги.

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

— Контакт-центр.

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

— Управление персоналом и расчет заработной платы

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

5.6.1.3. Использование преимуществ местоположения

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

5.6.2. Основной принцип аутсорсинга бизнес-процессов

Аутсорсинг бизнес-процессов следует одному базовому принципу, который наглядно проиллюстрирован на рис. 5.18. Представлен типичный сценарий, в котором три сервисных клиента ВРО перекладывают процесс на поставщика ВРО-услуг. Из-за специфических бизнес-требований на стороне клиента для поставщика услуг возникает проблема, что переданные на аутсорсинг процессы не являются идентичными. Отсюда вытекают очень серьезные требования к его гибкости, без которой он не будет конкурентоспособным на рынке. Кроме того, он должен действовать чрезвычайно чувствительно к затратам и оптимально ориентировать свою квалификацию на пользу клиенту. Подходящее решение предлагает представленная в разделе 4.5 архитектура управления бизнес-процессами Horus, в которой ориентированные на внедрение бизнес-сервисы отделены от специфических бизнес-процессов клиента. Кстати, само по себе внедрение клиентских процессов с точки зрения однородных бизнес-сервисов также представляет собой форму виртуализации.

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

На рис. 5.18 интеграционные компоненты изображены в виде слоя-посредника. О слое-посреднике мы говорим потому, что поставщики услуг стремятся к росту эффективности за счет масштабов деятельности (Economies of Scale) и поэтому постоянно пытаются все переложенные на них процессы внутри вести по возможности единообразно. Это выражается в значительной степени стандартизированных процедурах с соответствующими потоками управления и данных. Так как с другой стороны сервисный клиент хочет видеть внедренными свои индивидуальные требования, в слое-посреднике должно происходить ориентированное на конкретного клиента преобразование потоков управления и данных, которыми обмениваются между собой поставщик услуг и сервисный клиент. Кроме того, ВРО-клиенты также требуют — не в последнюю очередь из-за предписаний GRC (см. раздел 5.4) — значительной степени прозрачности относительно результатов процесса, а также самого исполнения процесса. Соответственно этому от поставщика услуг требуется предлагать ориентированную на клиента отчетность с понятными ключевыми показателями и аналитиками.

5.6.3. Основанное на моделях планирование и исполнение ВРО-договоров

Как уже следует из названия, все, что касается аутсорсинга бизнес-процессов, крутится вокруг темы бизнес-процессов, так что ВРО является естественной областью применения метода и инструментов Horus. И это справедливо для всего жизненного цикла ВРО-договоров. Кроме того, из предыдущих рассуждений должно быть более чем ясно, что ВРО предполагает общее понимание между клиентом и поставщиком услуг бизнес-требований, которые должны быть реализованы посредством передаваемых на аутсорсинг процессов. Это общее понимание можно формальным способом точно определить при помощи моделей Horus. Каким образом Horus может быть использован сторонами, участвующими в ВРО, и какие выгоды отсюда вытекают — предмет дальнейших рассуждений.

5.6.3.1. Точка зрения сервисного клиента

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

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

Из имитационного исследования и внутреннего технико-экономического обоснования следует затем основанная на моделях спецификация бизнес-процесса для передачи на аутсорсинг. Эта спецификация должна включать в себя ожидаемые свойства процесса: затраты, время, добавленную стоимость, качество, — а также соответствующие бизнес-объекты и систему ключевых показателей, посредством которых измеряется производительность процесса. Спецификация процесса, таким образом, формирует ядро технического задания, на основе которого осуществляется выбор поставщиков и объявление торгов на аутсорсинг.

5.6.3.2. Точка зрения поставщика услуг

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

Сначала поставщику услуг рекомендуется предоставляемые им бизнес-сервисы для многократного использования тщательно отграничить от отраслевых и специфических для клиента бизнес-процессов, как предлагается в рамках описанной в разделе 4.5 BPM-архитектуры Horus. Преимущество такого подхода в том, что и при адаптациях предлагаемого бизнес-процесса специально под клиента бизнес-сервисы все еще можно использовать главным образом в неизменном виде. Исходя из этого, поставщик услуг в поддержку своей службы продаж создает различные шаблоны процессов по отраслям. Эти шаблоны — апробированный способ наглядно представить потенциальным клиентам весь спектр предлагаемых услуг и выгоду от аутсорсинга бизнес-процессов. Опыт показывает, что такого рода анализ преимуществ ложится в основу разнообразных прогнозов ожидаемой нагрузки процесса. Очевидно, что для подобного анализа преимуществ имитационное моделирование может сослужить хорошую службу. Кроме того, анимация сеансов имитации проявила себя как убедительный инструмент визуализации в рамках презентаций с целью продажи.

Также в ходе подготовки предложения и прежде всего функциональной спецификации модели Horus находят свое применение. Они служат для формальной конкретизации спектра предоставляемых услуг и содержат помимо процедурных моделей также определения ресурсов, бизнес-объектов и ключевых показателей. Также — как принято для соглашений об уровне сервиса — должны быть заданы ожидаемые свойства процесса в виде затрат, времени, добавленной стоимости и качества. Кстати, на основе этих рассуждений можно также осуществить так называемое ценообразование на основе ценности (Value-based Pricing), то есть формирование цены, ориентированной на фактическую выгоду, полученную от аутсорсинга бизнес-процессов.

5.6.3.3. Значение отраслевых эталонных моделей

Рекомендации по использованию моделей на протяжении всего цикла ВРО-договора — от подходящего предложения на рынке через торги и котировки вплоть до исполнения договора — обнаруживают один главный недостаток. Он вытекает из необходимости сравнения или даже сопоставления моделей, которые создаются на стороне поставщика и клиента. Такой процесс может быть сколь угодно сложным и в любом случае накладным. Помочь здесь могут универсально-применимые эталонные модели, как, например, предлагаемые отраслевыми ассоциациями. В разделе 5.1.4 в качестве соответствующих примеров были представлены «Расширенная карта процессов деятельности телекоммуникационной компании (сокращенно: eTOM®)» от TeleManagement Forum и «Эталонная модель операций цепочки поставок SCOR®» от Supply Chain Counsil. Такие эталонные модели могут использоваться обеими сторонами договора в качестве общей точки отсчета. Очевидно, что таким образом двусторонняя подгонка моделей очень существенно упрощается.

5.7. Упражнения для самоконтроля

Упражнение 5.1

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

Упражнение 5.2

Реинжиниринг бизнес-процессов на основе моделей имеет много общего со строительством дома: после многих лет в вашем прежнем доме вы решились на строительство нового, при этом вы можете предоставить спецификации для строительного подрядчика несколькими способами.

— Желаемые характеристики нового дома задаются на основе старого.

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

Объясните, почему при каждом из этих подходов, вероятно, получится разный дом.

Упражнение 5.3

Изучите рис. 5.6 и назовите для торгового предприятия из упражнения 5.1 различные всеобъемлющие бизнес-процессы из области B2B и B2C. В будущем предприятие хотело бы предложить специальные условия для государственных организаций, для чего связь с ними должна осуществляться через сервисную шину предприятия (ESB). Как предприятие здесь может сотрудничать с одним или несколькими партнерами по разработке?

Упражнение 5.4

Объясните, как выглядит роль ключевого пользователя при внедрении бизнес-приложения. Обдумайте далее, как это происходит, если он использует Horus; сравните это с подходом при использовании исключительно общепринятого офисного инструментария. Какие из этого возникают риски?

Упражнение 5.5

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

Упражнение 5.6

Обдумайте, какие преимущества и недостатки возникают для предприятия после ориентирования его ИТ-сервисов на стандарт ITIL.

Упражнение 5.7

Приведите примеры аутсорсинга бизнес-процессов. Покажите в каждом конкретном случае, какие вы видите потенциальные выгоды (затраты, более быстрые процессы, лучшее качество продукта и т.д.).

5.8. Дополнительная литература

По теме реинжиниринга бизнес-процессов в предыдущих главах уже давались ссылки на литературу, например Hammer и Champy (1993). Gadatsch и Meyer (2006) специально посвятили свою работу становящемуся все более важным ИТ-контроллингу; сравните также с Kütz (2009). Delfmann и Becker (2007) обращаются к области эталонных моделей, а также процедурных моделей для предметно-ориентированной кастомизации. Процедурные модели широко распространены в информационных технологиях, например в связи с управлением качеством, в управлении проектами и прежде всего в разработке программного обеспечения; сравните, например, Chemuturi и Cagley (2010). Для углубления в тему сервис-ориентированной архитектуры обратитесь к Erl (2005, 2009) или Singh и Huhns (2005).

Темы ИТ-регулирования и ITIL, совершенно очевидно, тесно взаимосвязаны и поэтому часто обсуждаются вместе; сравните, например, Van Grembergen и Dehaes (2007). Библиотека инфраструктуры ИТ (ITIL) была разработана в конце восьмидесятых на фоне того, что организации становились все более и более зависимыми от ИТ и достичь бизнес-целей можно было только посредством эффективного внедрения ИТ. По поручению британского правительства должна была быть создана концепция управления, стандартизирующая и документирующая ИТ-сервисные процессы с целью улучшения управления и контроля за информационными технологиями в сфере государственного управления. Концепция управления, которую необходимо было разработать, также должна была помимо этого предъявить целесообразные и рентабельные методы для устойчивого улучшения ИТ-сервисов при одновременном снижении их эксплуатационных расходов. Несмотря на то что концепция управления изначально создавалась для госучреждений, быстро стало ясно, что благодаря своей абстрактности она также может быть перенесена на ИТ-организации и из других отраслей.

Об ITIL было опубликовано множество книг; для начинающих см. Persse (2010). Раздел 5.5.3 основан на работах Dr. Christian Bartsch. Дополнительную информацию по теме ITIL можно найти в его (немецкой) диссертации Bartsch (2010). Представление об актуальной третьей версии ITIL дают, например, Beims (2010) или Kittel и др. (2010). По теме виртуализации обратитесь к Menken (2010).

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

• Ассоциация TeleManagement Forum: .
• Расширенная карта процессов деятельности телекоммуникационной компании от ассоциации TM Forum (TM Forum Business Process Framework (eTOM)): .
• Ассоциация по управлению цепочками поставок (результат слияния в 2014 году Supply Chain Council с APICS): .
• Эталонная модель операций цепочки поставок (Supply Chain Operations Reference model (SCOR®)): .
• Язык описания веб-сервисов (Web Services Description Language (WSDL)): .
• Международная организация по стандартизации (International Organization for Standartization (ISO)): .
• Британский Институт Стандартов (British Standarts Institution (BSI)): .
• Форум по управлению ИТ-сервисами в Германии (IT Service Management Forum Deutschland e.V. (itSMF)): .

Отправить