Диссертация (1152223), страница 52
Текст из файла (страница 52)
Но последователи, забыв рекомендации, используют только функциональную декомпозицию. Интересно, что за моделями IDEF0 прочно закрепилось название функциональнаядиаграмма [239]. Последнее верно лишь в случае использования функциональной декомпозиции. Но если использовать декомпозицию по этапам жизненного цикла, с помощью диаграммыIDEF0 можно описывать процесс.Многие авторы отмечают схожесть понятий процесс и функция и возникающую вследствие этого путаницу. Этой теме посвящено множество публикаций [45] [240] [241].
Выделимстатью Ч. Беца «Ongoing Confusion of Process and Function» [242], в которой автор проанализи-199ровал справочные модели семейств ITIL, CMMI и COBIT. Он сравнил интерпретацию термина«процесс», используемую в этих моделях с определением, сформулированным А.
Шарпом иП. МакДермотт [62], которые утверждают, что: результат — самая важная часть процесса, безрезультата не бывает процесса; для каждого экземпляра исполняющегося процесса результатдолжен быть идентифицируемым и счётным. Если результат невозможно сосчитать, то мы имеем дело с функцией, а не процессом;Правильное имя процесса явно указывает на результат или конечное состояние процесса, продукт, который будет разработан, услугу и так далее.Благодаря приведённым критериям появляется возможность понять, имеем ли мы дело спроцессом или функцией. Если результат исполнения можно идентифицировать и посчитать, топеред нами процесс, если нельзя, значит функция.
Ч. Бец приводит многочисленные примерынесоответствий трактовки термина процесс в справочных моделях ITIL, CMMI и COBIT данному определению. Например, управление инцидентами, изменениями, качеством и т.д. не являются процессами, результат не счётный. Далее автор делает предположение, что именно различие в трактовке термина «бизнес-процесс» может быть одной из главных проблем, возникающих при практическом внедрении справочных моделей, иными словами, перейти от функциональной модели к процессной оказывается затруднительно.Ч.
Бец написал то, о чем многие подозревали, но боялись сказать: справочные модели,называемые Operation Reference, в большинстве случаев являются функциональными моделями, а не процессными. Чарли ссылается на свой опыт и здравый смысл, добавим новые аргументы в поддержку его тезиса.Справочные модели бизнес-процессовКак отмечают П. Лоос и П. Феттке, термин справочная модель в разных ситуациях можетиметь в различный смысл. Во-первых, он может обозначать: модель данных некоторой предметной области; во-вторых, модель лучших практик; в-третьих, «абсолютный» взгляд на то, изкаких компонентов и операций состоят процессы компании [243].
Модели данных находятсявне фокуса рассмотрения данной работы, поскольку процесс описывает работу, мы остановимся на двух последних трактовках этого термина. Лучшие практики описывают индивидуальныйопыт некоторой компании по реализации некоторого процесса — апробированный, воспроизводимый, структурированный и актуальный, способ достижения запланированных операционных результатов. Иными словами, это модель конкретного эффективного бизнес-процесса, созданная для предприятия определённой отрасли, внедрённая на практике и рекомендуемая дляиспользования при разработке/реорганизации бизнес-процессов на других предприятиях.
Какбыло показано выше в главе 1, подстраивая свои процессы под процессы лучших практик, ком-200пания теряет свою индивидуальность. Мы будем понимать под справочной моделью способописания бизнес операций организации, не привязанный к конкретной организационной структуре, которая выполняет эти действия. Этому определению соответствует каталог функций,иерархически организованный справочник работ, в котором перечислены все действия, выполняемые субъектами. Считается, что, имея «полный» набор функций, можно скомпоновать систему, применяя повторно используемые компоненты.Мы определили, что процесс описывает работу, которую необходимо выполнить, чтобыполучить запланированный продукт или услугу.
Зададим вопрос, что надо сделать, чтобы спланировать работу? Можно предложить воспользоваться приёмами проектного менеджмента, темболее, что многие отмечают существенные сходства между процессом и проектом [244]. Дляэтого следует составить список работ, которые необходимо выполнить, а затем, составить расписание исполнения указанных работ. В проектном менеджменте список работ получил название структурированная декомпозиция работ (WBS). Разработано множество техник составления такого списка, обычно используется декомпозиция работ. Однако, никто не задумывается овлиянии выбора стратегии декомпозиции на результат. Что бы исследовать способы декомпозиции процессов воспользуемся методикой, SADT.Модель SCORИсследуем справочную модель логистической деятельности SCOR [245], она имеет триуровня, именуемые: Process Types, Process Categories, Process Elements.
Документация упоминает четвёртый уровень Implementation Level, который не входит в состав модели, но, как считаютавторы SCOR, может быть «легко» получен из справочной модели. Если проанализировать, какие стратегии декомпозиции использовались при создании модели SCOR, показанной на рисунке 4.3, выяснится, что она построена путём функциональной декомпозиции.Что бы построить верхний уровень модели авторы задают вопрос: «что делает логистическая компания?».
Ответом является перечень видов деятельности: Plan, Source, Make, Deliver, Return. Возможно, кому-то покажется, что это декомпозиция по жизненному циклу, но, в таком случае, следовало бы явно выделить объект, этапы жизненного цикла которого мы анализируем.
Поскольку объект не выделен, декомпозицию следует рассматривать как функциональную. Этотуровень называется Типы «процессов». Второй уровень описывает «конфигурацию процессов».Каждый из элементов первого уровня подвергается функциональной декомпозиции, например,деятельность Plan разделяется на: Plan Source, Plan Make, Plan Deliver, Plan Return. Аналогичнопроизводится декомпозиция остальных видов деятельности.
Последний, третий уровень моделипоказывает процессные элементы, те самые кирпичики, из которых планируется строить сквозные процессы. Процессный элемент представляет собой цепочку операций, выстроенную в по-201рядке, определяемым последовательностью жизненного цикла продукта. Например, SourceStocked Products выстраивается в следующую цепочку, как показано на рисунке 4.2:ScheduleProductsDeliveries (S1.1)ReceiveProducts(S1.2)Verify Products(S1.3)TransferProducts(S1.4)AuthorizeSupplierPayments (S1.5)Рисунок 4.2 - Декомпозиция модели SCORИсточник: составлено автором.Первые элементы цепочки связаны общим объектом «Product», в последнем элементе используется другой объект управления «Payment», произошла смена объекта управления, причёмне понятно, связан ли платёж с одним конкретным продуктом или оплата может быть произве-Верхний1234Конфигурации1234Цепочки1234РеализацииУровеньдена позднее сразу за некоторое количество продуктов.1234МетрикиРисунок 4.3 - Уровни модели SCORИсточник: по материалам [245]Авторы модели утверждают, что собственно процессы (изображаются на не включённом всостав модели уровне Implementation) может быть составлены из процессных элементов третьего уровня.
Это действительно так, однако они умалчивают немаловажную деталь, придётся перебрать десятки процессных элементов, полученных трехкратной функциональной декомпозицией, чтобы найти нужный фрагмент. Процедура напоминает сборку паззла, с числом фрагментов превышающим 100, поиск может занять длительное время. Рисунок 4.4 иллюстрируетсложности, которые возникают при выборе процессных элементов, составляющих сквознойпроцесс [246].Модель SCOR скромно умалчивает о возникающих трудностях, однако аналогичные проблемы, возникающие при работе с моделью eTOM, нашли отражение в официальной документации Tele Management Forum.202453621Рисунок 4.4 - Сборка процесса из элементовИсточник: составлено автором.Модель eTOMКарта операций оператора связи eTOM, разрабатываемая Tele Management Forum, представляет собой справочную модель для классификации и описания с различным уровнем детализации всех бизнес-процессов оператора телекоммуникационных услуг связи [60].
Цель описания— определить основные понятия и компоненты из которых, как из кирпичиков, строится системауправления. Карту ошибочно называют моделью процессов. Анализ модели показывает, что онапостроена методом функциональной декомпозиции. Руководящие документы по eTOM регулярно упоминают термин бизнес-процесс, в том числе сквозные процессы, например, «Выполнение»,«Обеспечение» и «Биллинг» (Fulfillment, Assurance and Billing).
Однако эти «процессы» не соответствуют определению бизнес-процесса, данному А. Шарпом и П, МакДермоттом, посколькурезультат их исполнения не является счётным, нельзя сказать, сколько, например, биллинга выполнила компания за промежуток времени. Правильнее называть такую модель диаграммой деятельности, поскольку она перечисляет все функции предприятия.Для правильного понимания трактовки процессов в модели eTOM необходимо рассмотреть документ «GB921F — Representative process Flows» (примеры построения цепочек потоковработ) [247]. Документ призывает различать иерархию процессных элементов (описанных вeTOM) и цепочку потоков работ (workflow).
Документ следует воспринимать как иллюстрацию,демонстрирующую, что переход к потокам работ возможен, но не как практическое руководство. Описывается только общий подход, сценарии показывают лишь некоторые из возможных взаимосвязей, последовательности строятся на основе характерных вариантов исполнения.Рисунок 4.5 демонстрирует переход от модели eTOM к цепочке процесса. Как и в случае SCOR,процедура объединения процессных элементов в цепочку потоков работ не алгоритмизирована.203Рисунок 4.5 - Пример процесса телекоммуникационной компанииИсточник: по материалам [247]Проблема построения процессной модели на базе модели деятельностиФункциональная справочная модель представляет собой «идеальный» взгляд на деятельность организации.
Две компании, работающие в одной сфере бизнеса, должны выполнять одинаковые наборы действий, однако очерёдность операций в них может отличаться, посколькупредприятия обладают различной организационной структурой, производственной культурой ит.д. Справочная модель есть каталог функций, иерархически организованный справочник, в котором перечислены все действия, выполняемые субъектами [248]. Считается, что, имея «полный» набор функций, можно скомпоновать систему, применяя повторно используемые компоненты. Справочная модель обычно строится путём функциональной композиции, посколькуэтот способ является наиболее естественным для анализа системы, таким образом её следуетклассифицировать как функциональную. Сила и преимущество справочной модели заключается в том, что она строится сверху вниз и определяет иерархии компонентов системы.
Благодаря многоуровнему устройству функциональная модель позволяет выбирать подходящий дляконкретного рассмотрения уровень детализации.Проблема рассмотренных справочных моделей SCOR и eTOM в том, что в результатемногократной, повторной функциональной декомпозиции теряется логическая связь, описывающая очерёдность выполнения процессных элементов. Восстановить потерянную связь оказывается трудоёмко, что затрудняет практическое применение справочных моделей.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
