Ильин В.В. Моделирование бизнес-процессов. Практический опыт разработчика

Оглавление Введение ,<•- Глава 1. Концепция реинжиниринга и ' Л" и%* ^ - 11 с цть? ь 15 у * - г Глава 2. Концепция бизнес-моделирования 29 >* Глава 3. Методика описания и регламентации БМ Глава 4. Методика описания и регламентации БП 41 *1 59 - Глава 5. Качество моделирования 65 $ГЖ,Ъ < Глава 6. Бизнес-структуры компании и КИСУ Глава 7. Ошибки бизнес-моделирования „ ? 85 ^ ^ „ ■л / с»1| * Глава 8. Бизнес-модели компании '^ 97 105 Глава 9. Подведем итоги 113 Приложение А. Инструментальная среда АК18 127 Приложение Б. Расшифровка аббревиатур 163 ’апипф 4 *г < ь Литература _ ,,, ^ Л „ Предметный указатель ■1Ж1 I» Л 164 '«'П » <*• 1 г*. и *; нл. Тн. , ц'чыл т ф 7 . 165 Содержание Введение - От автора Для кого написана эта книга &!« Зачем написана эта книга Почему написана эта книга | Для чего написана эта книга , м ^ *' 5 « мй « Л Об авторе От издательского дома “ Вильямс” Глава 1. Концепция реинжиниринга 1.1. Подходы к реинжинирингу , 1.2. Роль БМ при подготовке к внедрению КИСУ 1.3. Необходимость ИТ-системного проекта Глава 2. Концепция бизнес-моделирования 2.1. Выбираем методологию описания БП 2.2. Задача поставлена: описать БП»11 ^ 2.3. Как будем описывать? 2.4. А что дает БМ? 2.5. Так что же должен уметь и знать СА? 2.6. Что же делать? 2.7. Кого выбрать? Глава 3. Методика описания и регламентации БМ 3.1. Архитектура БМ 3.2. Требования к организации работ по описанию БМ 3.3. Состав работ по описанию БМ 3.4. Требования к анализу качества и эффективности , работ по описанию БМ , *? , * 3.5. Порядок документирования и архивирования документов по БМ Г* -I к а* ? * г “ 56 / 3.6. Порядок внесения изменений в документы, регламентирующие выполнение БМ и ее БП 56 0 Глава 4. Методика описания и регламентации БП А Л Г. з п 4.4. Структура регламента выполнения гБП 1 . „ 4.5. Состав работ по регламентации БП ( * II 59 , 59 1 О. 4.2. Требования к описанию БП 4.3. Порядок описания регламента БП о I* 4.1. Методика описания БП ^ ' И( л • *. 1 п а н е ,} 60 61 62 и и, га,» * *+* 62 4.6. Требования к анализу качества и эффективности работ по регламентации БП 64 Глава 5. Качество моделирования $Г «? 55 65 5.1. Обеспечение качества моделирования 65 5.2. Оптимизация БП и определение их показателей 5.2.1. Подход к последующей оптимизации БП 5.2.2. Подход к разработке ССП <■„'1 5.3. Рекомендации по созданию БМ производственных процессов ,м 72 73 73 5.4. БМ — мифы и реальность * , < Миф первый: КИСУ внедряется в связи '* г -<!?«*с потребностями компании , Миф второй: для БМ важно правильно выбрать СА8Е-средство моделирования Миф третий: БМ — дело рук персонала только ИТ-подразделения Миф четвертый: БМ — это просто описание БП Миф пятый: имитационное моделирование БП позволит увеличить прибыль Миф ш естой и самый коварный: без БМ мож но обойтись Миф седьмой: при БМ можно обойтись без консультантов Содержание V* 77 78 79 80 $ 81 82 83 83 84 7 Глава 6. Бизнес-структуры компании и КИСУ 85 6.1. Роль и место СЮ в построении КИСУ 85 6.2. Взаимосвязь КИСУ с СМК 88 6.3. Роль маркетинга в управлении компанией 92 Глава 7. Ошибки бизнес-моделирования 97 7.1. Отсутствие четких целей и задач 97 7.2. Отсутствие ответственных лиц ^ 99 7.3. Отсутствие единого понимания (соглашения) 7.4. Лоскутное использование методологии 99 ''41* I 99 7.5. Внедрение в рамках отдельного проекта 100 7.6. Несвязанные направления документирования 100 7.7. Документирование в различных базах данных 100 7.8. Отсутствие обучения персонала 102 7.9. Документирование есть конечный процесс 102 7.10. Принятие необоснованных решений 102 7.11. Неполная информация по БП 103 7.12. Изменение требований 103 Глава 8. Бизнес-модели компании 105 8.1. Оптимальная модель СМК с использованием АШ 8 105 8.2. Модульный вариант бизнес-модели компании 110 ’ч “ Глава 9. Подведем итоги 113 9.1. Так как же правильно обустроить компанию? 113 9.2. Вместо заключения 123 Приложение А. Инструментальная среда АК15 у 127 *С А.1. Моделирование в среде АШ 8 128 А . 1.1. В ы б о р т и п о в м одел ей А Ш 8 д л я в ы п о л н е н и я Б М д 128 А .1 .2 . П р и м е р ы д и а гр а м м и м оделей 128 А .1 .3 . Р е к о м е н д у е м ы й п еречен ь и сп о л ь зу е м ы х ти п о в о б ъ е к т о в 8 135 Содержание Заполнение дополнительных атрибутов объектов организационной структуры подразделений Использование типов связей объектов моделей 141 142 А. 2. Практическое руководство по созданию моделей в АК18 .„ - 143 А . 2.1. Н а ч а л ь н а я н а с т р о й к а А К 1 8 Начальные настройки рабочей среды А Ш 8 Работа с системой АК18 на русском языке Н астройка сетки экрана моделирования Наследование прав доступа к папкам АК18 Н астройка привилегий на рабочих местах разработчиков .143 145 145 146 147 148 А . 2 .2 . О бщ и е п о л о ж е н и я п о м о д е л и р о в а н и ю 148 А . 2 .3 . Н а и м ен ов а н и е о б ъ е к т о в Разрешение конфликтов наименования объектов 149 150 А .2 .4 . С озд ан и е м од ел ей 150 А.З. Рекомендуемый регламент описания БП в еЕРС-модели АК18 Описание Описание Описание Описание Описание процесса Описание входов и выходов БП > ресурсного окружения технологий и участия руководителя цикла управления процессом контрольны х точек измерений и показателей отклонений от нормального хода процесса 156 ^ * 157 157 158 158 158 158 Приложение Б. Расшифровка аббревиатур 163 Литература 164 Предметный указатель 165 Содержание 9 1Г 'К ч; *г< 'г.ч ■ *,<■* -= - Ч Введение___________ 1 * Ж-4Н1 '* * а Щ5’(, 1 !Л, >,!.: !гд. • *) .4,'» (• Г, * ■н* ' -<> От автора Если делаеш ь что-нибудь неправильно — не нужно рассчит ыват ь на правильный результат. Народная китайская мудрость Для кого написана эта книга Эта книга написана не для специалистов — они уж е давно все тонкости этой темы хорош о знают. Эта книга написана для вас — Заказчиков и Потребителей Информационных систем или, как их принято называть, — ИТ-систем. П оэтому и позиционируется она как пособие по подготовке (или самоподготов ке) компании к разработке и внедрению системы управления производством. В книге вы найдете такж е реальную методику проведения и организации ра бот по бизнес-моделированию, которая демонстрирует действие процесса управ ления производством на практике. Зачем написана эта книга Понимание того, что компания работает не так прибыльно, как хотелось бы руководству, именно вследствие несовершенства системы управления, приходит не сразу. , г На первом этапе среднестатистический руководитель винит в отсутствии успеха нерадивых сотрудников. При таком понимании источника проблем со стояние дел в компании характеризуется ш квалом увольнений, кадровыми пе рестановками, наказаниями, штрафами или иными подобными мерами. Следующий этап осознания проблем организации относится уж е к актив ному использованию кадровы х механизмов. В это время компания пронизана проектами аттестации, переквалификации кадров, разрабатывается система мотивации труда, ориентированная на повышение производительности, пере краивается организационная структура. < <- Третий этап осознания первопричин неэффективности работы компании ха рактеризуется тем, что руководитель приходит, наконец, к пониманию, что все проблемы проистекаю т из неоптимальной системы управления. Причем видение назначения корпоративной информационной системы управления (КИСУ) переключается с организационной ст рукт уры на процессы реализации пост авленны х целей. Запад уж е прошел довольно длинной дорогой бесконечного реинжиниринга и автоматизации деятельности своих компаний и потратил на эти эксперимен ты миллиарды долларов. Нам тож е нужно, не повторяя ош ибок, совершенствовать свой бизнес и под нимать ВВП, н о не на 7% — за счет сы рьевы х ресурсов, а на 3 0 — 5 0 % — за счет повыш ения эффективност и управления (реального повышения качества биз нес-процессов (БП) — т.е. снижения накладных расходов). Почему написана эта книга На основании социологических исследований, проведенных в 2003 году И нститутом экономики переходного периода, выяснилось, что: • 8 3 % руководителей российских предприятий признают сущ ествование проблемы несовершенства системы управления и организационной струк туры и называют ее основной проблемой бизнеса. • 6 % компаний нуж даю тся во внедрении системы показателей эффектив ности деятельности. • 72% руководителей высказали намерение совершенствовать систему управления теми или иными средствами (внедрить систему оценки эф фективности подразделений и сотрудников, внедрить информационную систему, упорядочить бизнес-процессы). Таким образом, вопрос оптимизации управления компанией является сегод ня ключевым для топ-менеджеров большинства р оссийских предприятий. Для чего написана эта книга На сегодняшний день тема бизнес-моделирования обсуждается в огромном мно жестве работ самого разного масштаба. Но все они, как правило, носят теоретиче ский характер и предназначены, по большей части, для специалистов — системных и бизнес-аналитиков. По поводу внедрения КИСУ также уж е написано очень много хороших и правильных книг, и все же несмотря на это, долгое время занимаясь во просами бизнес-инжиниринга и моделирования бизнес-процессов в компаниях раз личного профиля и проблемами разработки и внедрения систем менеджмента каче ства, автору этой книги не раз приходилось сталкиваться с проблемами ясного тол кования основ всех этих процессов, связанными не только с процессами собственно разработки и внедрения КИСУ, но и с ее дальнейшим совершенствованием. 12 Введение Когда компания приглашает бизнес-консультантов, лексикон которы х полон загадочными аббревиатурами (ЕКР, ВР1, ТС}М и т.п.), то она, как правило, ждет от них слож ны х и трудно применимых к делу рекомендаций, что и затрудняет возмож ность понять очевидное. В этой книге материал изложен понятным и до ступны м языком, что помож ет читателю получить полное представление о дея тельности преуспевающей компании и по иному взглянуть на собственную. Р5 Конечно, не сущ ествует экспертов-специалистов по всем видам ИТ-деятельности одновременно. А бизнес-моделирование — как раз очень слож ный и мно гослойный процесс, поэтому мнение лю бого ИТ-специалиста по каж дому вопро су в процессе бизнес-моделирования мож ет быть субъективно, а с точки зрения другого ИТ-специалиста — даже необъективно! Именно поэтому автор не страдает манией величия и не приписывает себе роль создателя “ истины в последней инстанции” . Накопив знания из сопредель ны х ИТ-областей и освоив процесс внедрения различных информационных си стем (и систем управления качеством в том числе), я решил прокомментировать основные аспекты моделирования бизнес-процессов (МБП) и описать в качестве примера ту конкретную методику создания бизнес-моделей, которой пользуюсь именно с позиции “ практикую щ его” специалиста. Об авторе Ильин Владислав В ладимирович окончил факультет технической физики М осковского инженерно-физического института (МИФИ). Кандидат техниче ски х наук. До перестройки работал в институтах ВПК инженером-испытателем ВВТ (во оружений и военной техники), а позднее старшим научным сотрудником в ГосНИИ Авиационны х Систем. Р аботу в области СМК начал в 1998 году в качестве техн и ческого эксперта в систем е “ О боронсертиф ика” , где занимался консультированием и прини мал участие в проведении серти ф икац и онн ы х экспертиз СМК на предпри я ти я х ВПК. С 2003 года работает руководителем проектов по разработке и внедрению си стем менеджмента качества в системном интеграторе Тор8 Визшевз 1п1е§га1юг. До этого работал в телекоммуникационной компании “ Центральный Телеграф” менеджером системы качества, а еще ранее — в компании “ Ь и х о й ” (группа ком паний 1В8) инженером по качеству ПО. Имеет опыт управления проектами внедрения информационных систем, мо делирования и реинжиниринга бизнес-процессов (А Ш 8). Обладатель аттестатов “ Менеджмент качества” и “ Сертификация систем ка чества” , выданных в 1998 году центром “ Квалитет” (сертификация продукции Введение 13 и систем качества предприятий оборонны х отраслей промышленности); серт фиката БЫУ “ С^иаШу М апа^етеп!; 8узЪет” ; сертификатов РМР 1812-С180. “ Управление проектами” и 1812-С180.03 “ Управление рисками проектов”. Связаться с автором мож но по электронной почте: • У Н ул -п Э С та П .ги • ■г . <' > >и л.и1ас1@таа.1.ги От издательского дома “ Вильямс” Вы, читатель этой книги, и есть главный ее критик. Мы ценим ваше М1 ние и хоти м знать, что было сделано нами правильно, что мож но было сдела лучш е и что еще вы хотели бы увидеть изданным нами. Нам интересны люб ваши замечания в наш адрес. Мы ждем ваш их комментариев и надеемся на них. Вы мож ете прислать н, бумаж ное или электронное письмо либо просто посетить наш ЛУеЪ-сервер и осг вить свои замечания там. Одним словом, любым удобным для вас способом да те нам знать, нравится ли вам эта книга, а также выскаж ите свое мнение о то как сделать наши книги более интересными для вас. Отправляя письмо или сообщ ение, не забудьте указать название кни и ее авторов, а такж е свой обратный адрес. М ы внимательно ознакомимся с I ш им мнением и обязательно учтем его при отборе и подготовке к изданию нов! книг. Наши электронные адреса: Е -таИ : 1п ^ о0м 1 1 1 1а ш 5р и Ы 18Ь 1п д.сот Ь.’Ь’Ьр: //и и и . и И Н а ш з р и Ы г з Ь т д . с о ш Н аш и почтовые адреса: в России: в Украине: 115419, М осква, а/я 783 03150, Киев, а /я 152 ^ одО* I 14 '•--‘ - яг Введен)- Глава Концепция реинжиниринга__________ ■VII • ' V > -г' М ы имеем дело с множеством вещей, кот орых не можем сразу понять. Паоло Коэльо 1.1. Подходы к реинжинирингу Стремительный рост числа публикаций, посвящ енны х реинж инирингу, сви детельствует о том, что он становится доминирующ ей корпоративной логикой. В результате многие менеджеры стали заниматься реинжинирингом уж е по той причине, что об этой науке “одобрительно” отзы ваю тся средства массовой информации (часто имея весьма смутное представление об этом процессе). Этот “ бурный поток” публикаций породил и ш ироко ныне распространенную размы тость в толковании термина “ процессное управление” . Более того, многие менеджеры стали считать, что процессный и функциональ ный подход к управлению принципиально различны. Здесь не обошлось без уча стия некоторых, видимо далеких от практики, бизнес-аналитиков — это тот слу чай, когда сами консультанты являются источниками очевидной бессмыслицы! Они считают, что процессный подход — это что-то новое, передовое, эффек тивное, а функциональный — устаревшее и реакционное! Выходит, что до про цессного “откровения” мы шли “ не той дорогой, товарищ и!” ? И все это время сознательно плодили двойное подчинение, дублирование функций, искажали информационные потоки, так, что ли? Давайте разберемся. Ф ункция — это задача, которую решает компания для собственного вы ж и вания и для достиж ения поставленных целей. Ф ункция отвечает на вопрос что делать. Разумеется, в рам ках компании мож но выделить множ ество функций. Л юбая бизнес-система должна обладать такими функциями, как управ.® финансами, производство, продажи. А бизнес-процесс — это просто реализация функции во времени, способ р< ния бизнес-задачи. Б изнес процесс описывает то, как функция вы полняет ся, в какой после; тельности и в каких вариантах, а такж е то, как функции взаимодействуют I ду собой в работе компании. Бизнес-процесс отвечает на вопрос как делать П оэтому функции и процессы не являют ся противоположностями, а 1 ст авляю т лишь различные уровни абстракции. Обычно бизнес-процесс описы вают как путь, который проходит матерр ный объект или информация, — путь, который проходит заказ клиента п делам компании или новая идея в процессе разработки нового продукта. В с с этим в литературе принято определение бизнес-процесса как набора [ и процедур, преобразующ его входы в выходы, или, если по-простому, — о требляет р есурсы и производит полезный результат ([1]). И такой подход поддерживается рядом инструментальных средств моде) вания деятельности компании — например, А Ш 8 ([2]) или методики семе! ГОЕГ ([3]), которая раскрывает понимание процессов и функций. Одну ф ункцию мож но реализовать множ еством бизнес-процессов, и речь идет лиш ь о способе описания или о модели системы управления. 0} та ж е система управления мож ет быть описана как процессной моделью и функциональной. Ведь сама система мож ет иметь и двойное подчинение, блирование функций, и искаженные информационные потоки, а модель яв ся только отраж ением этой действительности. После визуализации системы (модель “ как есть” ) эти искажения необхс ликвидировать, что и предусматривает второй этап реинжиниринга — пос ние модели “ как должно быть” ! - — -------------------- — ----------------------- — -------------------------------- Не существует ни процессного управления, ни функционального — есть лишь эффек ное и неэффективное. А выбор типа модели для визуализации системы управления зависит о' кретной компании, конкретной рыночной ситуации, сум м ы всех значимы: тренних и внешних факторов и от выбранной ею стратегии. И все сущ ествую щ ие модели эффективного управления направлены на ние конкретны х управленческих задач. Запомните, что ни одна модель не< ет ваш у систему управления эффективной (это ж е модель, а не реальность Но! Она смож ет помочь вам оптимизировать саму систему управления пут» зуализации ее “ искажений” , и тем самым более или менее эффективно р< ту или иную управленческую задачу. Различные модели эффективного ущ ния, что бы ни говорили их авторы и некоторые бизнес-аналитики (как прг из числа тех, кто считает функциональную модель “ реакционной” ), пред] 16 [ чены, собственно говоря, только для визуализации методов и способов решения определенного круга задач. И выбирать модель следует исходя из понимания той конкретной задачи, которая стоит перед компанией. Если вы собираетесь строить Корпоративную Информационную Систему Управления (КИСУ), то вам для подготовки технического задания (ТЗ) на ее эскизный проект понадобятся обе модели (наглядно это показано на рис. 1.1). Если вы хотите внедрить систему управления качеством по стандарту 180 9001, то вам придется выбрать именно процессную модель ([4]), поскольку она действительно лучш е подходит для описания процессов “ удовлетворения” (на выходе) требований потребителей! Модель целей компании Модель стратегий компании Дерево продуктов или услуг Модели еизнеспроцессов 31 Модель ключевых показателей деятельности Процессная модель компании Модели управления (качеством, планированием, развитием и т .п ) Финансовая модель компании (экономическое планирование и бюджетирование) Рис. 1.1. Взаимосвязь между моделями отдельных функцио нальных элементов компании Концепция реинжиниринга т И скусство управления заключается в разделении основной задачи на подза дачи и организации мониторинга, касаю щ егося и х выполнения (анализ метрик в контрольны х точках на схеме, отраж аю щ ей последовательность действий и со бы тий при выполнении процесса). Разделение на подзадачи (а это и есть дерево функций компании) — это важ ный этап, именно от него зависит организационная структура (организационнофунциональная модель) предприятия. Это так называемая вертикальная декомпозиция, когда мы делим задачу на типы работ. Так, например, маркетинг мы разбиваем на изучение ры нков, анализ продаж , построение прогноза продай (а это и есть его прямые функции). Но для деления на этапы (последовательность) или сектора работ нам понадо бится уж е горизонтальная декомпозиция — разделение работ по внешнему по ставщ ику или потребителю, или по входам, результатам, рынкам, продуктам клиентам, регионам. Например, тот ж е маркетинг или закупки мож но разбит по регионам, или по продуктам, или по ключевым клиентам. Для этого уж нуж на “ процессная модель”. Д ругими словами, деление на типы и этапы или сектора — просто проекци деятельности компании на разные плоскости ее визуализации. Очевидно, что для структурирования различных частей организации (подразд лений) могут быть использованы различные подходы, более адекватные той бизне задаче, решать которую будет определенное подразделение компании (рис. 1.2). Рис. 1.2. Комбинирование вертикальной и горизонтальной декомпозиции 18 Гла Использование горизонтальной или вертикальной декомпозиции не потре бует принятия специальных организационных решений, создания или ликви дации подразделений, описания долж ностны х инструкций. В результате такой декомпозиции мож но создать вполне адекватную модель работы компании, к о торая помож ет реш ить насущные задачи, не прибегая к коренным преобразова ниям. И здесь опыт показывает, что горизонтальный подход действительно бо лее продукт ивен (рис. 1.3), так как более конкретен, нагляднее выявляет узкие места (визуализирует искажения) и позволяет сразу перейти от “ кто виноват” к “ что делать”. Однако это вовсе не означает, что надо “ что-то” в срочном порядке реорганизовывать, перераспределять и назначать. Достаточно проверить полу чивш ую ся модель на логичность и соответствие требованиям, которые выдвига ют различные факторы среды (устранить обнаруженные искажения). Поэтому, если слож илось ощущ ение, что в компании что-то не так, решение проблем нуж но начинать с вопроса, что должно быть реализовано, а не с вопро са, как это будет реализовано. Бессмысленно начинать реструктуризацию, пере краивать оргструктуру, оптимизировать бизнес-процессы без постановки кон кретных целей этого процесса! И начинать надо именно с поиска бизнес-задач, а не с постановки модного “ процессного управления”. В терминах реинжиниринга бизнес-процессов это называется “ поиском объектов” . А неудачный выбор таких объектов как раз и является основной причиной провала реальных проектов реинжиниринга. Функции Задачи М ею дика Критерии выполни мости Информаци онные ПОТОКИ Потребители сбора данных при н о с) роении бизнес -модели компании Бизнес - модель Структура 'VЧ > ..................................... - Метрики результатов компании Показатели эффективности работы Описание сквозных БП компании Диаграмма информационных потоков ---------- — Л ш - ................................................................................................................................................. .......................................................................................... .................................. Рис. 1.3. Концепция построения бизнес модели компании Концепция р е инж ини ринга 19 ~ Почему? Дело в том, что авторы ставшей уж е классикой книги “ Реинжиниринг кор порации” ([5]), Хаммер и Чампи, призывают заниматься реинжинирингом всей компании! Эти указания и берут на вооружение неподготовленные менеджеры. А заниматься надо реинжинирингом только тех процессов, в которых бизнесмоделирование обнаружило искажения! 1.2. Роль БМ при подготовке к внедрению КИСУ ’ На одной из выставок меня заинтересовали пять различных систем, которые реализуют концепцию корпоративной информационной системы управления — КИСУ. Все пять “ продавцов” любезно и активно рассказывали про возможности своих продуктов, но ни один из них даже не поинтересовался, в какой, собствен но, промышленной отрасли работает моя компания! И вряд ли когда-нибудь продавец скаж ет потенциальному заказчику, что предлагаемая система “ему, наверно, не подойдет”. То есть, фактически, не систе ма настраивается на предварительно реорганизованные процессы конкретного предприятия, а совсем наоборот. И в дело тут, как правило, идет наукообразное теоретизирование и заумные разговоры про “ практический реинжиниринг”. Поэтому в процессе формирования необходимых требований к конкретному КИСУ и возникает задача описания именно ваших конкретных бизнес-процессов (БП). Термин бизнес-процесс (БП) за последние годы приобрел популярность в кругу менеджеров крупны х и средних предприятий. Собственно, БП — это имеющие ся у лю бого предприятия процедуры, методы, технологии, с помощ ью которых оно функционирует, то есть извлекает доход из своей деятельности. Таким образом, ничего принципиально нового за термином БП не стоит. Своей возросш ей популярностью он обязан заложенному в нем подходу к управ лению: организация представляется не в виде набора функций (сбыт, производ ство, закупки, инвестиции, финансы), а в виде набора БП (планирование, прием и выполнение заказов, разработка новых видов продукции и т.д.). Управление такой организацией строится на основе управления БП. Переход от функциональной организации к процессной сопровождается только изменением технологий управления, т.е. делегированием владельцам БП полномочий, необходимых для самостоятельного принятия корректирующих воздействий. Изменения эти могут быть даже революционными — полное пере осмысление распределения ответственности и полномочий и, как следствие, — серьезное изменение организационной структуры компании. В этом случае говорят о реинжиниринге БП и создании корпоративной ин формационной системы управления (КИСУ) компанией. Для разработки КИСУ необходимо сначала построить модель деятельности предприятия, так называемую бизнес-модель (БМ). Построение такой модели ([6]) является результатом процесса бизнес-моделирования (БМд). 20 Глава 1 БМд — это системный подход к описанию целей, структуры, механизмов и регламентов деятельности компании и их связей между собой, направленных на достижение стратеги ческих целей и целей в области качества в том числе ([2], [3]). Из приведенного определения мож но сделать следующ ие выводы. • БМд — обязательный этап внедрения КИСУ. • Проведение БМд позволяет осущ ествлять такие действия: г . выработать общ ий язык для проектной группы и руководства; . . сократить время внедрения КИСУ; • разработать пошаговый план развития предприятия. • М етодология и используемое средство моделирования обеспечивают по нимание модели руководством. • Если исходный БП трудно документировать — это первый признак того, что данный процесс не оптимален. • Наличие отраслевой модели-заготовки значительно ускоряет процесс соз дания целевой БМ. Практика работы ИТ-компаний в этом направлении как раз и включает в себя подготовку таких заготовок, т.е. разработку типовых отраслевых архитектур БМ. Что ж е представляет собой КИСУ? КИСУ — это способ управления производственной деятельностью, обеспечива ющий достижение запланированных результатов (удовлетворенность потребите ля полученным продуктом или оказанной услугой) и позволяющий постоянно со вершенствовать эту деятельность (учет изменяющихся требований потребителей к продукту или услуге). На рис. 1.4 в стилизованном виде показан системный подход к организации эффективной КИСУ с помощ ью создания интегрированной бизнес-модели (БМ) компании. КИСУ в этой концепции состоит из двух основных модулей: • интегрированной БМ (ИБМ) — “ пирамида” структуры моделей БП не по зволяет снизить качество работ; • цикл управления процессами — цикл Деминга, представленный на ри сунке как “диск” Р ^ п ^ О о^ С Ь еск О А с^ оп , — обеспечивает вы сокую веро ятность достиж ения запланированных результатов, причем вероятность эта постоянно возрастает. Задача создания ИБМ реш ается путем бизнес-моделирования (БМд) ([6]) де ятельности компании. Задачу реализации цикла деминга решает цикл управления ИБМ. * ш Концепция реинжиниринга 21 Единым репозитарии всех моделей БП Объекты создаются и хранятся в едннои базе, что обеспечивает создание целостной ИБМ всей компании Рис. 1.4. Концепция системного содержания КИСУ Ц икл управления БМд включает в себя: • анализ внешней и внутренней среды компании, • планирование и разработку решений, • реализацию, учет, контроль, • анализ и корректировку возникаю щ их отклонений. Внедрение в компании элементов управления БМд позволяет: • ориентировать операционную деятельность компании на стратегические цели развития бизнеса и цели в области качества в том числе; • осущ ествлять контроль реализации корпоративной стратегии через си стему сбалансированных показателей деятельности (ССП или на запад ный манер — В8С); • визуализировать деятельность компании, обеспечив руководству возмож ность правильно оценить имеющиеся недостатки, находить возмож ности, сильные стороны и направления усовершенствования (постоянный реин ж иниринг БП); • осущ ествлять поддержку, регулярный мониторинг и управление измене ниями ИБМ компании; • поддерживать все стандарты и регламенты компании в актуальном состо янии; • оптимизировать деятельность по управлению развитием и изменениями. I ' Глава 1 Роль и место БМд в процессе выполнения проекта разработки и внедрения КИСУ показана на рис. 1.5. На схеме, представленной на рис. 1.6, приведен базовый план создания архитектуры ИБМ компании и практические способы ее создания. Обследование бизнеса компании Дерево услуг Рис. 1.5. Подход к построению КИ СУ компании Следует обратить внимание, что ИБМ всегда должна опираться на имитаци онные системы моделирования эффективности описанных БП, для того чтобы мож но было “ проиграть” варианты оптимизации БП. ССП — приводной ремень функционирования ИБМ: с ее помощью осуществля ется постоянный мониторинг (см. рис. 1.4) ключевых показателей деятельности (КПД) компании, анализ которых и закладывается в основу принятия управлен ческих решений. В БМд при разработке ИБМ самым оптимальным, как показывает практика, является смешанный подход — это когда моделирование идет навстречу: и сверху вниз, и снизу вверх. В этом случае наиболее полно реализуется как правильный вы бор целей и стратегий (руководство лучше знает рынок и внешнюю среду), так и не обходимая инициатива и поддержка всего персонала для их осуществления (народ лучше знает, как оптимизировать и настроить свою непосредственную работу). ИБМ компании, в соответствии с методологией, предложенной в [2], пред ставляет собой документированное описание: • стратегических целей и задач, •• • дерева продуктов и услуг, Концепция реинжиниринга » . , ■»*.* ’ , .. * 23 V • дерева функций, *- •!*» 1 • организационной структуры , • бизнес-процессов (БП) и процедур, • структуры информационных потоков и документов, • структуры данных и регламентов, • структуры ресурсов и прикладных систем, • взаимосвязи всех указанны х объектов и структур. Создаваемые высокоуровневые модели детализируются в низкоуровневых описаниях Коррекция высокоуровневых моделей Организационно1 функциональная модель компании Ролевые модели бизнес-процессов Модели структуры данны х Имитационные количественные системы моделирования Рис. 1.6. Процедура создания И Б М компании Сумма всех БМ, необходимых для полного описания бизнеса компании, и представляет собой ИБМ, пример архитектуры которой показан на рис. 1.7. В электронной базе репозитария БП (например, среды А Ш 8), предусмотрена вся необходимая их детализация и ресурсное окружение вплоть до уровня рабочего места. Модуль А Ш 8 В8С реализует ССП в рамках описанной ИБМ. Права доступа пользователя гарантируют персоналу санкционированный доступ к определенным частям базы данных А Ш 8 , поэтому каждый сотрудник видит на своем компьютере только те реальные процессы и функции, в которых он участвует (вместо пожелтев ш их от времени “ Рабочих инструкций” над рабочим столом), а руководители име ю т всю информацию по данным мониторинга всех КПД! В такой КИСУ отпадает необходимость и в составлении (а подчас “ вымучивании” ) долж ностны х инструкций, которые все время нуж но будет актуализиро вать в процессе управления изменениями при постоянном совершенствовании 24 Глава 1 всех БП — здесь все действия персонала “ по умолчанию” уж е расписаны в про цедурах того ж е репозитария БП и автоматически актуализируются при изме нениях в регламентах БП! Диаграмма целей и стратегий компании Формат модэпи -ОР______ гр Организационная структура компании Формат модели - I ОС ’ Дерево услуг Формат модели -Р\5Т нг Модели группы процессов Формат модели - УАР У Диаграмма структуры данных, документов и V информацион ных потоков Формат модели- Гг А— - Дерево функций компании Формат модели - 'рганизационная Ор| структура подразделений компании Формат модели • ОС кзо Модели сценария процесса Формат модели -УАО и еЕРС Модели процессов Формат модели - еЕРС Дерево функций подразделения Формат модели РТ Л тД Модели процедур Формат модели - еЕРС Диаграмма структуры информационных систем Формат модели -А50 Модели технических терминов Функциии или процедуры Формат модели ТТ Модели окружения Функциии или процедуры Формат модели РАО 21 Модели технических ресурсов Функции или процедуры Формат модели -ТЯ Рис. 1.7. Архитектура И Б М компании (форматы моделей даны в соответствии с функциональностью среды АК18) Остановимся теперь еще на одной очень важной задаче при разработке КИСУ, которую тож е решает БМд. В рамках решения задачи управления персоналом, который собственно и ре ализует стратегии и задачи КИСУ, сущ ествую т только две проблемы: Концепция реинжиниринга 25 • как сформировать высокий кадровый потенциал компании; . *•***. • как сделать труд этих “ кадров” действительно эффективным. Причины неудовлетворенности руководителей работой своих подчиненны* являю тся следствием неправильного решения одной из этих задач. Однакс прежде чем менять сотрудников, надо задать себе простой вопрос: “А знают лV они, что от них требуется?” . В традиционном подходе к описанию организации через “Должностные инструк ции” (“ вымученные” отделом кадров) предпринимается попытка выявления функ ций “целого” через функции “ частей”. Поэтому составленные таким образом доку менты всегда во многом расходят ся с действительностью и реальные требование руководителей к деятельности своих сотрудников остаются непрописанными. В процессе БМд сначала последовательно описываются стратегии, цели и функ ции компании, затем они распределяются по исполнительным звеньям вплоть д< конкретных сотрудников. Это и есть правильная постановка процесса управле ния персоналом, которая тож е обеспечивается БМд, как показано на рис. 1.8. Рис. 1.8. Процесс управления персоналом, в БМ д Построенная по такой концепции КИСУ будет работать четко, как швейцар ские часы, поскольку “ заведенный” в ней анализ результатов мониторинга клю чевых показателей деятельности будет постоянно подстраивать ее на оптималь ный реж им функционирования. 1.3. Необходимость ИТ-системного проекта Это единственный надежный рецепт, аккумулирую щ ий и согласованны! требования к вашей будущ ей КИСУ, и полную функциональную модель вашег ш ' » * . Глава компании с необходимой вам глубиной проработки — вплоть до уровня элемен тарных процедур каж дого из ваш их бизнес-процессов (рис. 1.9). Описание сквозных БП Описание Б Формулирование требований к фунционально прикладной архитектуре КИСУ Рис. 1.9. Этапы подготовки проекта И Т системы компании Безусловно, построение такой модели потребует значительных трудозатрат. И здесь будет интересно отметить, что поставщ ику программного обеспечения (ПО) строить ее иногда даже невыгодно, так как сравнительный анализ получен ны х требований к системе и функционала, предоставляемого предлагаемым им продуктом, вполне может привести к “ неожиданным” (или просто плачевным для поставщика) результатам. Ведь обы чно только 50% функционала предлагаемого ПО подходит для кон кретной компании, еще 30% необходимо переработать, а 20% вообщ е отсутству ет. Вот почему в рекламе по консалтинговым услугам обычно предлагается по строение именно информационной модели предприятия (что, куда, откуда), но нет ни слова о функциональном моделировании (кто, почему, зачем и как)! I *| И именно поэтому строить свою бизнес модель вы должны самостоятельно (о помощ и консультантов мы поговорим ниже)! С ущ ествую т методологии, ориентированные как на функционал, так и на поток данных. В первом случае первичной является функциональная модель, во втором, естественно, — информационная. Вот теперь вы можете вполне осо знанно сами выбирать, какая методология для вас все-таки полезней — функци ональная или информационная. Концепция реинжиниринга 27 Современная системная архитектура создается путем отображ ения биз нес-правил компании на функционал ИТ-системы (как показано на рис. 1.10). Именно поэтом у создание предваряющ его автоматизацию системного проекта служ ит прекрасной возмож ностью для оптимизации бизнеса, а такж е для про ведения эффективной работы по созданию перспективных планов развития. Бизнес-архитектура компании Структура бизнеса; процессы и Функциональная | структура приложений Система хранения и управления данными Оборудование и среда передачи данных*^^~[ Системная ИТ-архитектура компании Рис. 1.10. Формирование системной ИТ-архитектуры компании Таким образом, предваряющей автоматизацию системный проект служ ит прекрасной возмож ностью для оптимизации бизнеса, а такж е для эффективной работы по созданию перспективных планов развития. Подтверждением первичности функциональной модели служ ит то, что на про двинутом в области реинжиниринга Западе, где различные методики реоргани зации деятельности применяются уж е достаточно долго, до сих пор больш инство методологий (до 8 0 % ) являю тся именно функционально-ориентированными. И понятно почему: они не только интуитивно более понятны, но и обеспечивают правильную трактовку требований к будущей КИСУ. 28 • , Глава 1 Глава Концепция бизнесмоделирования Л учш ей материальной моделью кошки явл яет ся другая, а желательно та же самая кошка. Норберт Винер Любому инженеру хорош о известно, что управлять мож но только тем объек том, модель которого сущ ествует в системе управления этим объектом. Это н е обходимое условие управляемости. Поэтому основной целью моделирования бизнеса организации как раз и являет ся построение ее интегрированной модели или, в соответствии с современной кон цепцией управления изменениями, — процессной модели организации ([1]). На определенном этапе развития лю бой организации у ее руководства воз никает необходим ость в той или иной мере регламентировать ее деятельность, т.е. реально оценить сущ ествую щ ие БП и документально сформулировать, ка кими они должны быть для достиж ения запланированных результатов. Моделирование БП (далее МБП) — - это, прежде всего, инструмент руководителя (или владельца компании), при помощи которого он может добиться следующего: • облегчить жизнь своих подчиненных — посредством создания диаграмм БП, где в запоминающейся визуальной форме показано, кто, что И когда должен делать; • облегчить свою собственную жизнь, — уяснив что, кто и когда должен делать в организации, чтобы иметь возможность всегда сопоставить то, как есть на самом деле, с тем, как оно должно быть, и, следовательно, иметь постоянный ориентир для непрерывного улучшения деятельности компании. 1 ’* » Иначе говоря, МБП — это совершенно естественная вещь. т Задачав том, чтобы разумно использовать столь важный инструмент, как МБП, т.е. найти разумный компромисс между упрощением разрабатываемых моделей БП (взять только необходимое для достижения поставленных целей) с одной сто роны, и их усложнением (постараться учесть все влияющие на достижения ре зультата факторы) с другой. В любом случае, БМ зачастую хоть и выглядит чем-то не совсем естественным (модель всегда носит печать искусственности) и поэтому насильно прививаемым на всегда недостаточно подготовленную почву (и особенно на нашу, Российскую ), но оно абсолютно необходимо для формулирования требований к реализующей ее в дальнейшем ИТ-системе. 2.1. Выбираем методологию описания БП Мировоззрение человека формируется, как правило, методом, который он использует для реш ения своих проблем. Если он смотрит на организацию как на функциональную иерархию, то на обобщ енной модели БП он будет от о браж ать административную структуру. Если он — узкий финансист, то разра ботка модели БП начнется с описания финансовых потоков. Для ограничения этого многообразия необходимо привести модель БП в соответствие только с мет одом управления (и это самы й эффективный путь избеж ать неж елатель ного многообразия подходов). И здесь мы сталкиваемся с традиционной проблемой слож ности. Объект ана лиза всегда демонстрирует растущ ее количество своих свойств по мере его изуче ния. Модельер часто (потому что это, как правило, консультант, а не специалист компании) не всеведущ в понимании объекта и в определении достаточности па раметров, необходимых в процессе разработки модели. Слово “ модельер” здесь не очень подходит по звучанию, но вполне соответствует по смы слу — ведь если удалось получить адекватную модель, то это вполне мож но сравнить с “ поши вом удобного и красивого костю м а по фигуре Вашего Бизнеса” . При этом инструмент моделирования выступает не только как средство кон цептуального видения, но и как один из настраиваемых “фильтров” (механизм логического вывода), которые подавляют все многообразие до уровня восприим чивости модельером. А вот снижение многообразия как раз и является необходимым условием фор мирования навыков моделирования. Часто разработчики СА8Е-инструментов (СотриЪег Ак1ес1 б у зу е т Е п § т е е г т § ; — это просто программная среда, в которой можно проводить моделирование БП), стремясь продать свой товар, снабжают ин струмент избыточными свойствами (например, это свойственно системе А Ш 8). В результате ср о с т о м числа вариантов настройки “фильтра” (например, в АК18 — это возмож ность выбора одной из нескольких равноценных нота ций) повышается “ ш ум моделирования”. П оэтому инструменты м огут работать не только как “ ш умоподавители” (например, сниж ающ ее “ многообразие” семей ство методик ГОЕГ), но и как “ ш умоусилители” (например, АК18). Глава 2 В данном контексте сущ ествую т два основны х направления развития ин струментов МБП. Первое выражается в создании условий, сниж аю щ их степень свободы м о дельера. Это — определение ж естки х стандартов оформления умозаключений, обеспечивающих приемлемое взаимопонимание разработчиков и пользовате лей инструментов, поддерживающ их весь проектный цикл, но не позволяю щ их “творить” так, как нам хочется. Классическим примером такого подхода явля ется продукт В Р Ш п , поддерживающ ий стандарт ГОЕГО ([3]). Второе направление ориентировано на представление сервиса для выражения именно “творческих” взглядов на проектирование процессов. Например, методо логия А Ш 8 ([2]) предлагает рассматривать организацию с позиций 12 аспектов, представляющих разные взгляды на компанию, а также разную глубину этих взглядов. Для описания БП предлагается использовать 85 типов моделей (!), каж дая из которых принадлежит тому или иному аспекту. Свобода творчества! Другими словами, два подхода различаются количеством стандартных отно шений, которые представляет программная среда для описания БП. Все осталь ные известные стандарты проектирования БП обладают промеж уточными свой ствами в рамках описанных выше двух крайних подходов. Существующий стандарт ШЕР1, конечно, хорош для специалистов, если бы не “досадная” обязанность общ аться с заказчиком — а он должен хорош о и бы стро понимать схему, причем без специальной подготовки. Кроме того, синтаксические соглашения ГОЕГО делают модель очень статич ной. А при частом изменении объекта моделирования данные статичные модели просто выбрасываются за ненадобностью. ГОЕГО хорош о показал себя в оборон ной промышленности СШ А, где изменения происходят редко. Для реального бизнеса в условиях неопределенности ж есткие схемы моделирования, пред лагаемые ГОЕГО, лично мне каж утся малоподходящ ими — при изменении ор ганизационной среды потребую тся огромные переработки модели, формализо ванной на ГОЕГО.Вы можете назвать ПЖГО-модель, которая хотя бы через год после создания осталась актуальной для коммерческого предприятия в России? При объектно-ориентированном моделировании поддержание модели в акту альном состоянии намного упрощ ается. Но самое главное (и это очень важ ны й момент при согласовании и рецензи ровании моделей!), основной недостаток ГОЕГО-нотации состои т в том, что она очень трудна для понимания неспециалистами в области описания БП! Именно поэтому я рекомендую присмотреться к А Ш 8 . Данная среда моде лирования более понятна для неспециалистов в области описания БП (лучше один раз посмотреть, чем сто раз прослуш ать объяснения), что обязательно ска жется не только на вашей производительности при проведении моделирования, но и на “правильности” всех моделей, поскольку непонятое (и пропущ енное) при согласовании вполне может оказаться и неправильным! Концепция бизнес-моделирования 31 И по своему опы ту могу сказать, что понять диаграммы АК18 действительно намного проще (особенно руководству), чем диаграммы ПЖРО, ГОЕГЗ. Но это, как говорится, мое личное мнение и мой личный опыт, которые не являю тся исгиной в последней инстанции. 2.2. Задача поставлена: описать БП Процесс описания и оптимизации БП имеет уж е давно отработанную техн о логию, в которой сущ ествую т свои строгие правила ([1]). Она включает в себя цва основных технологических процесса: • описание БП (как есть); • моделирование БП (как должно быть). Основные процессы описания и моделирования БП показаны на рис. 2.1. » - - .. - ..— - .......... - .- .. ■— ..— » Описание БП предполагает построение модели предприятия “ как есть”. Моделирование БП — это построение новых моделей на базе уже имеющихся на предприятии (модель “ как должно быть” ). Рис. 2.1. Этапы описания и моделирования бизнес процессов Теперь по шагам и подробнее. 1. Разработка целей и стратегий компании. Обычно постановку целей осу щ ествляет руководитель или собственник компании. Сформулированные цели и задачи в дальнейшем м огут уточняться и детализироваться до 32 Глава 2 уровня подразделений. Это очень серьезный момент, поскольку именно для достиж ения поставленных целей и реализации стратегий и будет соз даваться интегрированная бизнес-модель (ИБМ) компании. 2. Ф ормирование проектной группы по описан ию и оптимизации ИБП. В проектную группу обязательно должны быть включены руководите ли подразделений, отвечающ ие за те основные процессы, которые бу дут оптимизироваться. Таких руководителей называют “ владельцами” процессов. В проектной группе они определяют процессы, подлежащие описанию и моделированию, план мероприятий, задачи и обязанности. Для участников проектной группы организуется обучение правилам и технологиям описания и моделирования БП. Далее проектной группой выбирается способ описания БП и составляется словарь терминов, к ото рый будет использован в работе. 3. Описание п роц ессов “ как есть” . Собственно описание включает в себя три процедуры: • сбор информации о БП предприятия (собеседования с участниками БП, анкетирование и т.д.); • построение моделей БП “ как есть” ; • согласование и корректировка моделей. 4. Моделирование БП. Это самый важный этап в работе группы. Именно на этом этапе вырабатываются решения, которые предопределят успешность бизнеса компании на рынке в ближайшей перспективе. Аналитики рас сматривают модель БП “ как есть”, осущ ествляю т поиск “ узких мест” и со ставляют рекомендации по оптимизации. Затем проектная группа выстра ивает модель “ как должно быть” с учетом рекомендаций и поставленных перед проектной группой целей. В заключение данного этапа проводится процедура согласования, коррекции и утверждения модели в компании. 5. Организация и проведение работ по изменению сущ ествую щ и х БП в с о ответствии с моделями “ как долж но бы ть” . На данном этапе выстраива ется план мероприятий по внедрению изменений в сущ ествую щ ие про цессы предприятия, определяются способы , очередность изменений, раз рабатываются новые регламенты и стандарты, технологии выполнения работ и операций, проводится обучение сотрудников и руководителей. 6. Анализ проведенных изменений. Включает анализ эффективности проведен ных изменений, их соответствие поставленным целям. При необходимости разрабатываются корректирующие мероприятия. 7. Регулярный мониторинг БП. Вырабатывается система мониторинга (оцен ки) эффективности БП: стоимость, скорость, качество выполнения и т.д. Результаты сравниваются с выработанными показателями эффективности (ПЭ) — как, подробно будет обсуждаться ниже. Концепция бизнес-моделирования 33 2.3. Как будем описывать? Л ю бому инженеру хорош о известна схема классической универсальной моде ли контура саморегулирования, которая представлена на рис. 2.2.Наличие об ратной связи — это основополагающ ее свойство всех управляемых систем, оно является необходимым для функционирования и управления БП. Рис. 2.2. Схема функционирования бизнес процесса Как правило, ошибки на этапе моделирования БП в состоянии “ как есть” не столь критичны. Ошибки на этом этапе могут привести лишь к тому, что будут получены не совсем корректные оценки повышения производительности процессов после построения моделей в состоянии “ как должно быть”. Как правило, при вне дрении любой информационной системы вам придется выполнить моделирование вплоть до каждой элементарной операции и каждого документа. И тут очень важно правильно определить необходимость существования каждого документа, посколь ку именно избавление от паразитных документов (документов, не добавляющих ценности) и приносит существенную экономию и времени и средств. При построении моделей БП в состоянии “ как есть” порядок их получения особой роли не играет. Однако предварительно рекомендуется составить модель цепочки добавленной ценности — для того, чтобы разграничить область дей ствия отдельных процессов “ по крупному” . Далее каж ды й процесс, входящий в данную цепочку, декомпозируется до требуемого уровня детализации. Главное здесь — согласовать процессы верхнего уровня именно по входам и выходам. Куда более важно постараться избавиться от ош ибок на этапе построения мо делей БП в состоянии “ как должно быть”. При построении модели в состоянии “ как долж но быть” больше подойдет схема нисходящ его проектирования (про ектирования “ сверху вниз” ). Дело в том, что зачастую при объединении двух процессов в один удается достичь дополнительного повышения его эффективно сти — часто имеет место ситуация, когда некоторый процесс на поверку может оказаться просто паразитным. м о»* .?-*•*<> Глава 2 На практике не раз видел такое. Потрясут рисунками привлеченных для описания БП сту- м дентов, мол, у нас уже все есть. А что там есть? Соответствуют ли описанные процессы , реальной действительности или нет? Этого никто не знает — разбираться в этих “ непо нятных картинках” в действительности никто и не собирался (опять повод присмотреть ся к АР15). И когда начинаешь эти процессы анализировать и пытаешься использовать их при построении архитектуры КИСУ — вот тут самое интересное и начинается: то по явление документов из ниоткуда, то создание документов, которые не имеют потреби теля и т.д. и т.п. В результате после долгих мучений приходится выбрасывать эти модели и выполнять всю работу заново! Вот почему моделирование БП компании должны вы полнять профессионалы (а не студенты, наскоро обученные нотациям). Конечно, важ но понимать, что модели БП далеко не всегда будут отличаться полнотой и непротиворечивостью. Модель БП помож ет обнаруж ить узкие места только в малой доле случаев, которые нас могут интересовать. А вот главное — что и как менять — они не подскаж ут, и здесь сработают только профессионалы, которые смогут правильно “ прочитать” интегрированную бизнес-модель (ИБМ). И если формализовать знания “ п рактикую щ их” консультантов, то мож но полу чить полные и универсальные модели по разным профилям производственной деятельности, на основе которы х впоследствии будут успеш но реализованы все проекты по моделированию бизнес-процессов. Можно пойти иным путем — обратиться к теории систем и абстрагировать ся от бизнес-среды. Есть определенные закономерности развития систем, и все инженеры это прекрасно и давно знают. В первую очередь это упорядочивание. А любое упорядочивание должно иметь закономерности — не надуманные, а ис текающие из самого сущ ества разрабатываемой системы. ----- Г, Следует понять сущность, осознать смысл, и только потом строить модели. — ..... - ............... .... И если наконец вам удалось связать выделенные процессы в единую модель (т.е. вы создали непротиворечивую ИБМ компании), состыковать ресурсы и доку менты в эту систему — вы получаете ни что иное, как проект архитектуры КИС (рис. 2.3)! В результате такого подхода вы получите исчерпывающий список тре бований к необходимой именно вам ИТ-системе, а далее — на ваше усмотрение! А теперь тестовый вопрос: “ Чего в вашей компании больше — специфики (уникального) или стандартного (универсального)?” Если вы считаете, что все компании уникальны на 80 % , а стандартны на 20 % , то я утверж даю , что на са мом деле все совсем наоборот: для каж дого предприятия характерно лиш ь 20 % уникальности и 80 % стандартного. Если считать, что вы правы, то вашему предприятию нуж но разрабатывать собственную, особенную КИСУ. Если прав я (а в 90 % случаев, поверьте практику, это так и есть!), тогда компания мож ет вос пользоваться готовой ИТ-системой, например ЕКР-класса (Еп^егргчве Кезоигсе Концепция бизнес-моделирования Р 1 а п тп ё — система планирования ресурсов предприятия), с подходящей референс-моделью, и на первых порах пренебречь 20 % своей уникальности, сделав главный упор на 80 % стандартного в своих ключевых БП. >1. 1 Рис 2 3 Этапы построения функционально прикладной архитектуры КИСУ 2.4. А что дает БМ? Для этого проанализируем традиционные (особенно “ традиционные” для рос сийского менталитета) проблемы, которые встречаю тся практически в любой компании. • Отсутствие структурированной системы получения данных от подразде лений. • Несогласованность действий м еж ду служ бами. • Дублирование работ. • Отсутствие отлаженной системы документооборота меж ду отделами. А причина только одна — больш ое количество обособленных операций сое диняется только через управленческий аппарат, что неизбежно влечет большие ш Глава 2 расходы на взаимодействие меж ду подразделениями (в денежном, временном и т.д. выражениях), как показано на рис. 2.4. Функциональная модель управления (вертикальная) Транзакционный шум при функциональной системе управления может составлять до 80% от времени исполни \ $ $ ! I % Рис. 2.4. Различие в схеме документооборота для функциональной и процессной систем управления ? 4 Вспомним закон Паретто “ 80\20” (50% работ ы выполняет 20% персонала или 20 % населения обладают 80 % богатства страны). I Так вот, согласно статистике, в типичной бизнес-системе он тож е действует: 20 % времени занимает выполнение собственно операции, а 80 % времени уходит на передачу информации: на рабочем месте человек выполнил свою функцию, пе редал руководителю информацию о выполненной работе, далее информация по падает к секретарю, лежит пару дней у него на столе, после чего попадает на стол руководителя. И далее в обратном порядке. Получается значительная задержка, а может даже и искажение информации (прошло много времени и на данный мо мент показатели могут резко измениться). Если сомневаетесь, то можете прохро нометрировать процесс движения того или иного документа в вашей компании. Но кто ж е способен проделать всю эту кропотливую работу по моделирова нию? Вот именно для такой работы обы чно и прибегают к услугам бизнес-ана литиков (или, как их еще называют, системны х аналитиков), владеющ их мето дологиями перевода бизнес-идей на транзакционный уровень. И именно таких специалистов особенно недостает сегодня в российских компаниях. Мне ближе термин “системный аналитик” (СА), так как компания рассматривается, прежде всего, как единая бизнес-система. СА способен рассуждать по принципу “от общего к част ному” , а не только наоборот, что характерно для узкого функционального специалиста. Концепция бизнес-моделирования т 2.5. Так что же должен уметь и знать СА? Ответ на вопрос, поставленный в заголовке данного раздела, в стилизованном виде представлен на рис. 2.5.В вашей компании есть такие специалисты? Если нет, то вам нуж но их взять на работу или вырастить, обучив кого-то из продви нутого ИТ-персонала. Функции системного аналитика [ Требования к о пы ту и знаниям I системного аналитика Знание современны х Внедрение (вы бор, «■ обучение, эк ш л уа ш ц н я } м ею дологи й и среде»» моделирования ** I Оам'-сре 1СI в и методоло! ив Ф \н ш м ещ а л ьн ы е ш;шии в о б л а сш \ правления Соддзиие, проверка адекваш есш и ■нанмное со» ласование всех моделей т ..!. ... .. и...,........... ......... Внедрение И С для уиранленн» компанией сложными е т ч е м а м и О ны ! 5ч а с т я в н р о е т а х , с в я ш ш ы х с \правленческим |>онс\ л[,1 ироиаиием либо с ав»ом »»и*анией нре ш р и я »ий Знание реальны х проблем \ правления нреднрин I нем Рис. 2.5. Функции системного аналитика и требования к профессиональным навыкам Наличие системного аналитика — это необходимое условие, но не достаточ ное. П ридется все-таки обращаться к консультантам. В последнее время на руководителей лю бого рода предприятий обруш и лась тьма консультантов, предлагающ их внедрить различные системы управ ления. При этом они, как правило, используют англоязычные термины (ВРК, ЕКР, ТС}М), вызывающ ие у слуш ателя чувство собственной неполноценности. И каж ды й предлагает только свое решение (опять звучат англоязычные назва ния систем: Огас1е, ВАА1\Г, ЗАР, Ахар1;а и т.д.), не объясняя, чем оно отличается от других и в каки х случаях его лучш е применять. Но, вообщ е говоря, руково дитель вовсе не обязан знать все тонкости каж дой ИТ-системы — последним долж ны заниматься как раз внутренние системные аналитики. Глава 2 2.6. Итак, что же делать? г ,ч « ал Из выше изложенного вы уж е поняли, что описание БП является слож ной и трудоемкой задачей ([6]), требующ ей хорош ей профессиональной подготов ки, и нуждается в конкретной методологической и инструментальной платформе ([2], [3]). Но для вас формулировка такой задачи еще нова и своими силами вы пока не в состоянии успеш но разработать бизнес-процессную модель свей компании. * Где же вы х од ? Да там же, где и в х о д ! Разумно воспользоваться идеей бенчмаркинга (это новомодное слово означает всего лишь “ изучение передового опыта и внедрение его у себя” ). Для выполнения этой работы можно привлечь консультантов и объединить их в одну группу со сво ими внутренними СА (из числа продвинутого персонала или взяты х на работу специально для дальнейшей поддержки БМ). В совместно образованной группе моделирования рекомендуется обязательно предусмотреть роль администратора бизнес-моделирования (АБМ). Его основная и очень необходимая для построения целостной БМ обязанность — контроль целостности бизнес-модели и ее непроти воречивости с позиций взаимных стыковок описаний отдельных БП. На ранних стадиях создания бизнес-модели ф ункцию АБМ должен выпол нять как раз внешний консультант. Но ему понадобится дублер из команды за казчика, который мог бы перенять опыт, а затем полностью принять базу полу ченных моделей для последующ его управления изменениями. Для постоянной актуализации БМ в дальнейшем будет необходим ваш собственны й АБМ , обу ченный ранее у консультанта. Любое знание, и бизнес-модель в частности, имеет смысл, только если постоянно исполь зуется на практике. Как только модель перестает отражать реальное состояние дел в ком пании, все усилия по ее созданию будут сведены на нет. 2.7. Кого выбрать? Первое. При выборе консультантов существенное значение имеет наличие у них готовых отраслевых моделей (вот для чего они полезны в первую очередь — что бы не изобретать велосипед своими силами). Прежде всего, это свидетельствует об уровне их профессионализма в вашей области. Кроме того, наличие модели-заго товки позволит значительно сократить время на описание рутинных БП, которые, каким бы уникальным вы свое предприятие не считали, всегда составляют поряд ка 80 % от общего числа (поверьте практикующему консультанту). Как правило, типовыми БП всегда являю тся логистика, бюджетирование, закупки, выбор поставщ иков, продажи и т.п. Второе. Очень важ но умение консультанта увидеть пресловутые “ 2 0 % моде лей, которые описывают 80 % деятельности” — вот для чего они полезны во вто Концепция бизнес-моделирования ш рую очередь (хотя, может, как раз и в первую) — чтобы “ велосипед” не оказал ся “ мерседесом” . И это, поверьте практику, сэкономит уйм у времени и ваших средств (рис. 2 .6 ). Почему выгодно приглашать консультантов для моделирования визнес-процессов компании? Нет своих бизнесаналитиков или они пока не знакомы с бизнесмоделированием VI ыии внешний консультант Позволяет эффективно обучить своих СА на лучшем и признанном опыте и избежать повторения чужих ошибок Наличие у консультантов готовых отраслевых моделей и заготовок наиболее типичных БП Ж Умение консультанта увидеть пресловутые 20% из всех моделей , в которых сосредоточено 80% знания о компании Позволяет сократить срок создания единой БМ до одного-двух (в зависимости от “мощности” компании) месяцев вместо 6-12 при опоре только на “внутренние силы”! Рис 2 6 Причины обращения к профессиональным консультантам для создания Б М компании /Г Р8. Сейчас на каждой третьей визитке написано “ Бизнес-аналитик" или “ Бизнес-консультант”. Пользуйтесь услугами тех, кто имеет прослеживаемый опыт моделирования именно в вашей отрасли1 и Глава 2 5 Глава Методика описания и регламентации БМ М а ст ерст во — эт о когда “что” и “как” приходят одновременно. В.Э. Мейерхольд Ниже, в качестве конкретного примера, приведена используемая автором методика создания БМ и описания входящ их в нее БП. БМд осущ ествляется п у тем разработки набора взаимосвязанных моделей, входящ их в ИБМ и описыва ющих деятельность компании. Документирование ИБМ выполняется путем создания репозитария БМ. При создании репозитария будем исходить из следующего. • Всестороннее описание структуры и деятельности компании обеспечива ется набором взаимосвязанных моделей, отраж аю щ их различные аспек ты ее организационно-функциональной структуры . • М аксимальная наглядность описания деятельности компании достигает ся путем поэтапной детализации ее организационной структуры и бизнеспроцессов, т.е. путем создания иерархии организационно-функциональ ных моделей. • Должна быть обеспечена простота актуализации моделей при изменении организационно-функциональной структуры компании. • Должен быть сформирован широкий спектр отчетов о состоянии организаци онно-функциональной структуры компании, выполненных в различных сре зах. В частности, должно быть обеспечено формирование положений о под разделениях компании и должностных инструкций специалистов. Применение для документирования организационно-функцион&лъноиструк^ туры компании специализированной среды моделирования, например А Ш 8 , обеспечит ([2]): • создание репозитария моделей; • хранение моделей как части базы знаний компании, в частности, интегра цию репозитария в корпоративный информационный портал, если тако вой будет создан; • отчуж даем ость моделей от конкретны х исполнителей; • доступность моделей специалистам компании, в частности, возможность использования их для ознакомления новых сотрудников с деятельностью компании; • поддержание моделей в актуальном состоянии силами собственны х спе циалистов компании; • поддержание в актуальном состоянии силами собственны х специалистов компании долж ностны х инструкций и положений о подразделениях ком пании; • анализ возм ож ны х вариантов изменений в организационно-функциональ ной структуре компании; • формирование ш ирокого спектра стандартных и специальных отчетов о состоянии организационно-функциональной структуры компании в раз личны х срезах, что особенно эффективно при лю бы х изменениях, произ водимы х в организационно-функциональной структуре компании. 3.1. Архитектура БМ Комплект бизнес-моделей компании заказчика представляет собой докумен тированное описание ледую щ их элементов: • стратегических целей и задач, • дерева продуктов и услуг, • дерева функций, • организационной структуры , • бизнес-процессов и процедур, • структуры информационных потоков и документов, • структуры данных и регламентов, . , • структуры ресурсов и прикладных систем, < ■, яда* <„ ,, ^ • взаимосвязи всех указанных объектов и структур. 42 Глава Сумма всех БМ, необходимых для полного описания бизнеса компании, пред ставляет собой ИБМ, проект архитектуры которой был представлен на рис. 1.7. Выбор форматов моделей для описания БМ компании определяется как требо ваниями к разработке КИСУ, так и результатами проведенного системно-анали тического обследования его деятельности консультантами. В составе БМ выделяется несколько уровней детализации бизнес-процессов компании. • I условный уровень — БП компании в целом, рекомендуемая глубина де тализации — 2-3 уровня. • II условный уровень — БП подразделения компании (возмож на детализа ция операций БП I уровня), рекомендуемая глубина детализации — 2-3 уровня; • III условный уровень — БП рабочего места подразделения (возможна дета лизация операций БП II уровня), рекомендуемая глубина описания — 1-2 уровня. БМ может состоять как из моделей БП и других моделей, так и из одного БП; иначе говоря, модель БП — это тож е БМ. Уровень детализации БМ и ее БП явля ется условным понятием, определяемым для задач разработки его моделей. Для целей регламентации БП должен бы ть выбран уровень описания, удоб ный для понимания выполняемых операций всеми его участниками. Каж дый БП может быть детализирован в модели от верхнего уровня до ниж него уровня, если это целесообразно. Целесообразность детализации модели определяет его владелец совместно с выш естоящ им руководителем. Выбор цели и формата опи сания БМ и ее БП осущ ествляет ее владелец совместно с вы ш естоящ им руково дителем и внешним консультантом. В табл. 3.1 приводятся модели и их форматы, рекомендуемые для описа ния БМ в зависимости от поставленных целей. Содержание предлагаемых БМ, их связи с другими моделями и источники информации для построения показа ны в табл. 3.2. . Таблица 3.1. Рекомендуемые модели и их форматы для описания БМ в среде АК15 Цели описания БМ Название модели Формат модели в среде АК15 Описание БМ уровня компании Диаграмма целей Организационная структура Дерево услуг Дерево функций компании Сценарий группы процессов Диаграммы структуры знаний и документов 0 0 (0Ь]есЙуе 01адгат) ОС (0гдаШ2а1юпа1 СНаг1) Р /5 Т (Рго<1ис(/5етсеТгее) РТ (РипсЯоп Тгее) УАй (Уа1ие Ас1с1ес1 сЬат 01адгат) КЗО (Кпо\«1ес)де 31гис1иге 01адгат) Методика описания и регламентации БМ 43 Окончание табл. 3.1 Цели описания БМ Название модели Формат модели в среде АК15 Регламентация БМ уровня компании Сценарий группы процессов Сценарий процесса Диаграмма прикладных (информационных) систем Диаграммы структуры знаний и документов Диаграмма информационных потоков УАО (Уа1ие Аййеб сЬат Ошдгат), Р5М (Ргосезз Зе1ес1юп Ма(пх) РЗО (Ргосезз Зе1ес1юп 0|адгат) АЗО (Арр||са(юп Зуз(ет Р|адгат) КЗО (Кпо\м1ес1де 5*гис1иге Ршдгат) 1Р0 (Ногта1юп Р1оуу 0|адгат) Описание БМ уровня структурного подразделения Дерево функций подразделения Организационная структура Сценарий процесса Диаграмма прикладных (информационных) систем Диаграммы структуры знаний и документов Диаграмма информационных потоков РТ (Рипс1юп Тгее) ОС (0гдап12а1юпа1 СЬаг*) РЗй (Ргосезз 5е1есИоп 0|адгат) АЗО (Арр 11са1юп Зуз1ет 0|адгат) КЗО (Кпо\м1ес1де 31гис1иге 0|адгат) Расширенная событийно-процессная еЕРС (ех!епс1ес1 Еуеп( Опуеп Ргосезз СУгат) РАО (Рипс1юп АПоса1юп 0|адгат) АЗО (Арр||са1юп Зуз^ет Р|адгат) КЗО (Кпо\л/1ейде 51гис*иге 0|адгат) 1Р0 (1п^огта(юп Р1о\л/ Ошдгат) Разработка регламента выполнения БМ структурного подразделения цепочка Ресурсное окружение функции Диаграмма прикладных (информационных) систем Диаграммы структуры знаний и документов Диаграмма информационных потоков Расширенная событийно-процессная Описание БП для рабочего цепочка места исполнителя Диаграмма прикладных (информационных) систем Ресурсное окружение функции Технические термины Технические ресурсы Разработка регламента выполнения БП для рабочего места исполнителя Расширенная событийно-процессная цепочка Ресурсное окружение функции Технические термины Технические ресурсы 1Р0 (1пк>гта1юп Р1о\л/ 0 >адгат) еЕРС (ех1епс1ес1Еуеп! Опуеп Ргосезз СНат) АЗО (Арр||са1юп 5уз1ет 0|адгат) РАО (РипсИоп АПосаНоп Оаадгат) ТТ (Тесйшса! Теггп) ТК (ТесНтса! гезоигсез) еЕРС (ех1епс1ес1 Ечеп! Опуеп Ргосезз СЬат) РАО (Рипс1юп А11оса1юп 0|адгат) ТТ (ТесЬтса! Тегт) ТК (ТесЬтса! гезоигсез) V- 44 ^ Т а б л и ц а 3 .2 . С о д е р ж а н и е п р е д л а га е м ы х Б М , с в я зи , и с т о ч н и к и и н ф о р м а ц и и Содержание БМ Связи с другими типами моделей Источники информации Ой (0Ь/ес(1уе Дерево целей компании 0|адгат) Деревья целей подразделений - - Строится иерархия ее целей и стратегий, определяются критические факторы и процессы, обеспечивающие достижение этих целей (как целые направления деятельности компании, так и конкретные БП) Декомпозиция целей — путем построения дерева целей подразделений (для удовлетворения внутренних потребителей в компании) Проецируются на модели ОС (0гдаш2а1юпа1 СЬаг1) и Р /8 Т (Ргос1ис1/ З е т с е Тгее) Бизнес-план компании Интервью с руководством и руководителями подразделений ОС (ОгдашгаИопа! Организационная СЬаП) структура компании Организационная структура подразделений Описание групп сотрудников Описание должностей Структура объектов управления Структурирование объектов организационной диаграммы верхнего уровня определяется соподчиненностью элементов организационной структуры компании Объем описания на данном уровне ограничен описанием должностей руководства компании и подразделений прямого подчинения. Структура отдельных подразделений и должностей должна быть представлена на отдельных моделях этого типа при последующих уровнях детализации Для описания бизнес-ролей персоналий с организационных диаграмм используется детализация объекта “должность” (Розеол) с помощью модели этого же типа (показываются должности, бизнес-роли, персоналии и местоположение детализируемой должности) На этой диаграмме показываются организационные единицы (объекты управления) и отношения подчинения между этими объектами (связи) Проецируются на модели Р /3 Т (Ргос(ис1/$еплсе Тгее) и РТ (Рипс1юп Тгее) Детализация объектов на моделях того же типа ОС (ОгдашгаЪопа! СИаг4) Организационная структура компании Положения о подразделениях Интервью с руководителями подразделений Должностные инструкции персонала Интервью с руководством Типы моделей Формат АК15 У / Продолжение табл. 3.2 Содержание БМ Связи с другими типами моделей Источники информации Модель “Дерево продуктов/услуг” применяется для описания продуктов и услуг для внешних потребителей компании. Имеет иерархическую структуру и пишется “сверху— вниз”. Продукты и услуги делятся на две группы продуктов — внешние продукты (для удовлетворения клиентов) и внутренние продукты (для удовлетворения внутренних потребителей в самой компании) Проецируются на модели ОС (ОгдатгаНопа! СИаг(), РТ (РипсИоп Тгее) и УАО (\/а1ие Ас1с1ес1 сМат 0|адгат) Детализация на модели УАО (\/а1че АсШеЬ сНат 01адгат) Бизнес-план компании Интервью с руководством и руководителями подразделений Дерево функций применяется для описания иерархии функций компании по оказанию услуг (и производству продукта). Описывает состав БП на уровне иерархии бизнесфункций подразделений Проецируются на модели Р /8 Т (Ргос1ис1/Зеплсе Тгее) и ОС (Огдашгайопа! СМаП). Детализация объектов на моделях РАР (Рипс1юп АМосаНоп 01адгаш) и УАР (Уа1ие АсМей сЬат 01адгат) Интервью с руководителями подразделений Положения о подразделениях Интервью с функциональными специалистами Используется для описания процессов верхнего уровня компании путем структуризации множества БП, посредством которых осуществляется ее деятельность на группы процессов и на матрицу БП Детализация объектов на моделях: РЗМ (Ргосе55 8е1есЯоп Ма1пх) и Р50 (Ргосезз Зе1ес(юп 01адгат) 1 Л Интервью с функциональными специалистами Типы моделей Формат АК13 Дерево услуг компании Дерево услуг подразделений внутри компании Р /5 Т (Ргос1ис1/ ЗегасеТгее) Дерево функций компании Дерево функций подразделений внутри компании РТ (Рипсйоп Тгее) Сценарий групп» процессов УАЭ (\/а1ие Ас1йес1 сЬат 0|адгапп) * [ ! р С>()п Л'>‘Г о / П К !С )Л 3 Типы моделей Формат АК18 Содержание БМ Связи с другими типами моделей Источники информации Классификация группы процессов Р5М (Ргосезз 5е1ес1юп Ма1пх) Диаграмма выбора процессов используется для описания состава процессов в виде набора родственных сценариев процессов, включающих необходимое число процедур Модель содержит два измерения — перечень сценариев и перечень процедур Проецируются на модель Р5Р (Ргосезз Зе1ес1юп Р|адгат) Детализация объектов на модели еЕРС (ех1епс1ес1 Еуеп( йпуеп Ргосезз С(1а т) Интервью с функциональными специалистами На этой модели показываются все знания компании В рамках данной модели все объекты могут быть детализированы на модель классификации документов для более подробного описания На модели отражаются группы документов и входящие в них документы Детализация объектов на моделях А5Р (Арр||са1юп Зуз1ет 0|адгат) и ТТ (ТесИтса! Тепл) Интервью с функциональными специалистами Интервью с ИТ — специалистами Документы, описывающие БП и регламенты их выполнения На этой модели показываются все информационные потоки компании В рамках данной модели все объекты могут быть детализированы на тех же моделях для более подробного описания На модели отражаются также каналы коммуникациий между подразделениями в процессе получения и передачи документов Проекция на АЗО (Арр1|са1юп 8уз1ет 0|адгат) и КЗО (Кпо\л/1ейде 51гисШге 0|адгат) Детализация объектов на моделях 1Р0 (1п(огта*юп Р1о\п/ 0|адгат) Интервью с функциональными специалистами Интервью с ИТспециалистами Документы, описывающие БП и регламенты их выполнения Диаграммы структуры знаний и документов Модель классификации документов г КЗО (КпоуИедде 31гис1иге Ошдгат) >! уО -и Диаграммы структуры информационны*., потоков * * ч ш т ->4 Щ И о гп Ч Ч р " Й о т Р|адгае|г) • * , ' у. 1> М 2 Продолжение табл. 3.2 Типы моделей Формат АК15 Содержание БМ Связи с другими типами моделей Источники информации Классификация информационных систем Диаграмма прикладных (информационных) АЗО (АррПсайоп 5уз1ет 01адгат) Модель применяется для описания прикладных информационных систем компании. На верхнем уровне иерархии располагаются классы информационных систем, которые выделяются по функциональному признаку. В состав каждого класса входят информационные системы (программные комплексы, базы данных, приложения и т.п., относящиеся к данному классу) Проекция на модель К8Р (Кпо\л/1ес1де 51гис1иге 01адгат) Детализация объектов на моделях ТТ (ТесЬшса! Теггп) и ТР (ТесНтса! Резоигсез) Интервью с ИТ — специалистами Описание используемых ИТсистем Диаграмма выбора процессов используется для описания состава процессов в виде набора родственных сценариев процессов, включающих необходимое число процедур. Модель содержит два измерения — перечень сценариев и перечень процедур Детализация объектов на модели еЕРС (ех1епс1ес1 Еуеп( йпуеп Ргосезз СНат) и Р50 (Ргосезз Зе1ес((оп 01адгат) Интервью с функциональными специалистами Сценарий процесса Модель процесса Модель процедуры ’госеэз I р|'адгат) еЕРС (ех4епс1ес) Модель сценария процесса предназначена для описания алгоритма выполнения отдельного Ргосезз СНат) сценария или процесса (процедуры) в виде еЕРС (таИпа! Яо\м) последовательности процедур (действий), еЕРС (Рот сИзр1ау) управляемых событиями. В этой модели главное внимание уделяется последовательности выполнения еЕРС (Со1игпп процедур (действий), составляющих данный сценарий. сКзр1ау) Модель представляет собой последовательность событий и функций, отражающих логику выполнения взаимосвязанных действий, направленных на достижение заданного результата (заключения сделки, оформления сделки и проч.) ЕуеМ Опуеп Исполнители Документы, проецируются описывающие на модель ОС БП и регламенты (Огдатгайопа! СНаг1). их выполнения. Детализация объектов Интервью на моделях РАО со специалистами (Рипс(юп АНосаНоп подразделений 01адгат); ТТ (ТесЬтса! Тегт) и ТР (ТесИтса! Резоигсез) о к о н ч а н и е т а о л Ти п ы м о д е л е й Ф орм ат А К13 Ресурсное окружение функции Модель окружения функций используется РАО (Рипс1юп А11оса*юп 0|адгат) для детализации функции модели процедуры. Это позволяет разгрузить модель процедуры и более детально описать бизнес-роли исполнителей функций, входящие/исходящие документы функции, информационные системы и другие ресурсы, используемые при выполнении функции. Модель является опциональной. В случае ее использования на модели процедуры ресурсное окружение функции не показывается 2 Л Й ' 1 Технические термины С вя зи с д р у ги м и ти пам и м оделей И сточни ки инф орм ации Детализация объектов на моделях ТТ (ТесЬшса! Тегт) и ТГС (ТесИтса! Резоигсез) Документы, описывающие БП и регламенты их выполнения. Интервью со специалистами подразделений У ТТ (ТесМтса! Тегт) Описание иерархии выбранной предметной области можно производить с помощью модели технических терминов. Термин представляет собой некоторое понятие, с которым работают или которое используют функции и процессы. Термины могут иметь материальное воплощение в виде показателей, а могут и не иметь такого Проекция на модель КЗО (Кпо\л/1ес1де 31гис1иге 0|адгат), Детализация — на другую модель ТТ для подробного описания Интервью со специалистами подразделений. Документы, описывающие БП и регламенты , их выполнения ТК (ТесИтса! Кезоигсез) Модель описывает иерархию используемых компанией технических ресурсов. Описывает используемые технические ресурсы, их иерархический состав, а также физическое местоположение и соотношение с организационной структурой Проецируются на модель ОС (0гдаш2аИопа1 СНаг1). Детализация — на другую модель классификации ТК Интервью с техническими специалистами подразделений С Технические ресурсы. Классификация технических ресурсов С о д е р ж а н и е БМ Описание форматов моделей в среде А Ш 8 представлено в приложении А . Обозначения, используемые далее в рисунках (взяты х из репозитария БП в среде А Ш 8 ), приведены на рис. 3.1. Стандарты и регламенты Например, РМВоК и 150 9001 Бумажная версия документа. Электронная версия документа или файл Пакет проектных документов Црль дейтельности или показатель удо в пэт в сренности клиента Содержание работы или функции Поикладная система Например М2 Ргоде! М5 ОиНоок М5 ОКюе Команда проекта Руководитель отдела и/м проекта Интренет сайт Показатель процесса или работы Рис 3.1. Обозначения элементов БМ , взятые из среды АЕ18 3.2. Требования к организации работ по описанию БМ Заказчиком работ по описанию и регламентации БМ мож ет быть любой из вы сш их руководителей компании, в сферу ответственности которого входят соответствую щ ие направления деятельности. Сами указанные работы отраж аю тся в плане разработки (внесения измене ний) нормативно-методических документов обеспечения управленческой дея тельности (далее плане) как разработка нормативно-методического документа, регламентирующ его БМ. Заказчик определяет владельца БМ. Владелец БМ ука зывается в плане проекта как ответственный за проведение работ. Работы по описанию БМ выделяются в отдельный проект (либо подпроект, если они являю тся частью другого проекта). Владелец БМ по согласованию с вы ш естоящ им руководителем определяет кандидатуру руководителя проек та. Кандидатуру руководителя проекта утверждает заказчик. Занятость руко водителя проекта в работах по проекту в обязательном порядке учитывается при планировании его загрузки по основной должности. Для выполнения работ по описанию БМ формируется рабочая группа. Рабочая группа формируется из сотрудников подразделений, выполняющих БМ, по пред 50 Глава 3 ложению руководителя проекта. Состав рабочей группы согласуется с владель цем БМ и вышестоящим руководителем. Численность рабочей группы составляет от трех до шести сотрудников в зависимости от слож ности БМ. Руководитель проекта согласует загрузку членов рабочей группы в работах по проекту с их непосредственными руководителями. Рекомендуемые функции руководителя проекта при описании, регламен тации и анализе БМ представлены на рис. 3.2. Роли и ответственность членов рабочей группы определяются руководителем проекта при планировании работ по проекту, как показано на рис. 3.3. Руководитель проекта моделирования | выворБМ и определение I целей их описания Выбор нотаций их представления с учетом рекомендаций настоящей методики Соглашение о моделировании Обучение рабочей группы и владельца БМ Рис. 3.2. Роль и ответственность руководителя проекта БМ д Методика описания и регламентации БМ Разработка и согласование "Соглашен! (рМОДЙЛИрОЙ Специалисты компании { Проведение интервью Моделировщик БП Моделировщик Б1 .„[фйрмированнй V Г 1^ЯЯИВ" I моделей Е.»1 Моделировщик БП АК13Т00)8е1 Системный Г Х Ё ъ __ щ } Рис. 3,3, Роли и ответственность членов рабочей группы по описанию Б М и ее БП 3.3. Состав работ по описанию БМ ~ Схема процесса описания БМ представлена на рис. 3.4.План работ по описа нию БМ по шагам приведен в табл. 3.3. 1 1 \ Приказ о назначении владельцев БМ и ее БП Рис. 3.4. Схема процесса описания Б М и ее БП Методика описания и регламентации БМ 53 Таблица № шага 1 1.1 1.2 13 2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 3 4 14 3.3. План работ по описанию БМ Наименование работ Состав работ Принятие решения Ответственный/ исполнитель Результат Заказчик Протокол совеща» Распоряжение о проведении работы по описанию БМ владелец Проведение совещания с высшим руководством Владелец Протокол совеща! Создание рабочей группы Владелец Распоряжение о назначении раб< Г Р У П П Ы И р у КОВОЦ1 проекта Руководитель проекта План работ Проведение предварительного совещания Владелец Протокол совешг Сбор существующих документов по БМ Руководитель проекта Документация по получена рабоче группой Планирование и организация работ I -1 Изучение существующих Руководитель материалов проекта по описываемой БМ и другой действующей нормативной документации Перечень существующих документов с кр аннотациями Формирование перечня документов по БМ Руководитель проекта Перечень докум по БМ сформир! Формирование глоссария проекта по описанию БМ Руководитель проекта Глоссарий про& описания утвер) Разработка программы и календарного плана работ по описанию БМ Руководитель проекта Проект програи описания перед на согласован» Согласование и утверждение Программы описания и календарного плана работ Руководитель проекта Программа опи утверждена Выделение необходимых ресурсов для ведения проекта описания БМ Владелец Руководитель проекта получ* необходимые^ Определение владельца БМ Назначение владельца БМ Заказчик Приказ о назн< владельца БМ Определение клиентов и выходов БП Формирование перечня и спецификаций на выходы и клиентов БП Владелец Уточненный пе и специфика^ согласованы с потребителя и утверждены Окончание табл. 3.3 №шага Наименование работ Состав работ О тветственный/ исполнитель Результат 5 Определение поставщиков и входов БП Формирование перечня и спецификаций на входы и поставщиков БП Владелец * Уточненный перечень и спецификации согласованы с поставщиками и утверждены 6 Определение используемых ресурсов Формирование перечня и спецификаций на ресурсы БМ Владелец 7 Определение операций БМ Формирование перечня операций БМ Владелец Уточненный перечень операций согласован с владельцем БМ 8 Разработка и согласование “ Соглашения о моделировании” в компании заказчика Руководитель проекта Заказчик Соглашение о моделировании БМ см. Приложение А " * 9 Формирование графических схем БМ Руководитель проекта С» ! ! * ,4.гя Уточненный перечень и спецификации согласованы с владельцем БМ 9.1 Выбор типа модели в среде АК15 для описания БМ в соответствии с соглашением Рабочая группа Выбор типа **'" * модели согласован с владельцем и заказчиком 9.2 Описание модели в выбранной нотации среды АК15 Рабочая группа Проект модели описан в выбранной нотации 9.3 Проверка корректности моделей Рабочая группа Модели, проверенные на корректность 9.4 Проверка адекватности моделей Специалисты компании Модели, проверенные на адекватность 9.5 Документирование и утверждение моделей Рабочая группа Утвержденная подшивка графических схем моделей Определение трех групп показателей: показателей БП, показателей продукта БП, показателей удовлетворенности клиентов БП Рабочая группа, специалисты компании 1* $ 10 Определение показателей БП Лг Утвержденный перечень показателей >м- \ 3.4. Требования к анализу качества и эффективности работ по описанию БМ 8 т чч «в '» * и > Анализ качества и оценку эффективности выполнения проекта проводит руко водитель проекта. Результаты оценки оформляются им в виде отчета и содержат: Методика описания и регламентации БМ 55 • анализ “ план/факт” по исполнению календарного плана работ по проекту; • замечания и рекомендации по организации проекта. Управление организационного развития проводит дополнительный анализ ка чества и эффективности работ по описанию БМ на основе следующих критериев: • степень соответствия разработанной документации по БМ требованиям настоящ ей методики; • степень удовлетворенности потребителя (заказчика описания БМ) резуль татами проекта. Руководитель проекта, владелец БМ и представитель заказчика проводят совещание по обсуж дению результатов выполнения проекта, его качества и эф фективности. При необходимости руководитель проекта, владелец БМ и пред ставитель заказчика выясняют причины низкого качества и /ил и эффективно сти проекта и разрабатывают мероприятия по его улучшению. Руководитель проекта отвечает за контроль исполнения выработанных мероприятий. 3.5. Порядок документирования и архивирования документов по БМ Порядок документирования, архивирования документов по БМ устанавлива ется в соответствии с требованиями к хранению и архивированию нормативно методических документов компании заказчика. 3.6. Порядок внесения изменений в документы, регламентирующие выполнение БМ и ее БП Владелец БМ один раз в год проверяет действующ ий регламент на соответ ствие реально сущ ествую щ им БП. Владелец БП обязан проверить соответствие регламента сущ ествую щ ему БП в случае значительных изменений: входов/вы ходов БП, ресурсов, технологии его выполнения. Владелец БП должен проверить регламент в случае получения от выш естоя щ его руководителя неудовлетворительных результатов анализа БП. По итогам рассмотрения владелец БП может принять решение о продлении действия регламента без изменений или о необходимости пересмотра регламента. Владелец БП согласовывает с выш естоящ им руководителем принятое ре шение о продлении действия регламента без изменений или о необходимо сти пересмотра регламента в порядке, установленном в компании заказчика. При согласовании принятого решения предоставляются документальные осно вания принятого решения, а именно: 56 ’ '*■ ‘ * | * - * з ' Глава 3 • предложения других подразделении и предприятии компании, • результаты анализа установленных и предвидимых несоответствий, • рекомендации внутренних или внешних аудитов, • другие документы. Схема этой процедуры представлена на рис. 3.5. Порядок мониторинга БМ и ее БП П г 1 (к а д е й ' Ное ый регламент Рис. 3.5. Схема процедуры, внесения изменений в Е М Правила моделирования и описание форматов моделей в среде А Ш 8 в виде проекта соглашения о моделировании в соответствии с методологией, предлага емой в [2], представлены в приложении А . Рекомендации по описанию регламента выполнения собственно БП в среде АК18 представлены в приложении А . Методика описания и регламентации БМ 57 с I Глава Методика описания и регламентации БП Прежде чем куда-то идти, узнай, где ты находиш ься! Народная китайская мудрость Модели БП, как это уж е упоминалось выш е, входят в состав БМ. Описание бизнес-процесса должно содержать следующ ие характеристики: • входы и поставщ иков; • выходы и клиентов; • ресурсы: • персонал, • оборудование, • информация, . среда; • технологии его выполнения; • этапы цикла управления; * • • контрольные точки для измерения показателей его эффективности; • возможные отклонения от его нормального хода; • показатели и данные удовлетворенности его клиентов; • контроль руководителя. 4.1. Методика описания БП Описание, регламентация БП и последующ ая оценка его эффективности должны рассматриваться как три этапа работ по БМд ([2], [3], [4]) — рис. 4.1. ЭладелецБП Э п и ^ т „ г и е1 пь. л 1г»с с г - ^фирМИ^ОЬ (НИН ь*пдн 1нй ‘Кикр|ТЬ'1 ' Формирование регламента выполнения. бкгмбс-процесса V- О цени эффективности - У ? Ш Рис. 4.1. Этапы работ по регламентации Б П 4.2. Требования к описанию БП На верхнем уровне любые БП должны рассматриваться, как показано на рис. 4.2, а с учетом их иерархии — как на рис. 4.3. . * 'г <•< Рис. 4.2. Схема описания БП " I -'Ч 60 Глава 4 "Ч ** * БР N . 2 Рис. 4.3. Схема иерархического представления БП 4.3. Порядок описания регламента БП Схема описания регламента БП показана на рис. 4.4. Рис. 4.4. Схема методики регламентации Б П I'"***»»**#-*-''»,■аду*” Методика описания и регламентации БП 4.4. Структура регламента выполнения БП Структура документа “ Регламент выполнения БП” является типовой и фор мируется в соответствии с установленным в компании заказчика порядке. Работы по регламентации БП организовывает и отвечает за их результатив ность и эффективность владелец БП. Работы по регламентации БП может выпол нять та ж е рабочая группа, которая создавалась для его описания в рамках БМ. Ответственный за разработку или коррекцию этого документа совместно с представителем заказчика формирует план разработки документа и утверждает его у владельца БП. Владелец отвечает за выделение ответственному исполните лю всех необходимых ресурсов для разработки документа. Контроль сроков и качества разработки документа осуществляет владелец БП. 4.5. Состав работ по регламентации БП ,г ь Регламент выполнения БП содержит перечень инструкций, которые определяют порядок выполнения работ (операций, БП нижнего уровня), которые необходимо: • увязать в единую систему (организовать взаимодействие и сты ковку по форме, результату и временным параметрам); • разработать заново, если их нет или они устарели. Началом работ является внесение в план проекта сроков разработки, выпу ска или корректировки документа “ Регламент выполнения БП”. Регламентация БП по шагам представлена в табл. 4.1. Таблица 4.1. Регламентация БП № шага Наименование работ Состав работ Ответственный / исполнитель Результат 1 Формирование структуры регламента и определение перечня форм На основании собранной информации по БП рабочая группа формирует разделы регламента выполнения БП Рабочая группа Шаблон регламента 2 Определение и утверждение матрицы ответственности Формирование матрицы ответственности БП в соответствии с данными описания (см. табл. 4.2). Утверждение матрицы ответственности в БП Рабочая группа Владелец БП Матрица ответственности по БП (см. табл. 4.2) 3 Определение показателей БП Рабочая группа согласует с владельцем БП перечень целевых показателей БП и вносит их в соответствующий раздел регламента Рабочая группа Владелец БП Перечень целевых показателей БП 62 « ШМ'Г Н иг' • * *• Глава 4 Продолжение тобл 4 1 'шага Наименование работ Состав работ Разработка регламентов мониторинга БП Разработка регламентов Рабочая группа мониторинга БП, определяющих Владелец БП периодичность и порядок анализа результатов деятельности БП Ответственный / исполнитель Результат Регламенты мониторинга БП, определяющие периодичность и порядок анализа его результатов Разработка регламентов анализа со стороны владельца БП и формы их отчетности. Анализ эффективности БП со стороны владельца БП проводится на основании результатов выполнения установленных показателей эффективности БП. Форму и периодичность отчетности подразделений и сотрудников БП устанавливает его владелец. Регламент анализа со стороны владельца БП устанавливается - исходя из требований оперативного управления его ходом и планирования достижения установленных его целевых показателей Рабочая группа Владелец БП Разработка регламента анализа со стороны вышестоящего руководителя и форму для документирования анализа результатов. Анализ эффективности БП со сто роны вышестоящего руководителя проводится на основании резуль татов выполнения установленных отчетных показателей БП. Форму и периодичность отчетности вла дельца БП устанавливает вышесто ящий руководитель (заказчик) Рабочая группа Вышестоящий руководитель Согласование с поставщиками/ клиентами БП спецификации его входов/выходов. Владелец БП утверждает спецификации входов/выходов Рабочая группа, поставщики/ клиенты БП Владелец БП Согласованные спецификации входов/выходов БП Согласование Согласование с владельцем БП с владельцем спецификации на ресурсы БП спецификации на ресурсы БП Рабочая группа Владелец БП Согласованные спецификации на ресурсы БП Разработка регламентов анализа БП - Разработка регламента анализа БП со стороны вышестоящего руководителя Согласование с поставщиками/ клиентами БП спецификаций его входов/ выходов тодика описания и регламентации БП Регламенты анализа БП * Регламент ^ анализа со стороны вышестоящего руководителя *-» ! 63 Окончание табл 4 1 № шага Наименование работ 9 Состав работ Ответственный / исполнитель Результат Формирование Формирование окончательного перечня документов по БП, окончательного согласование его с владельцем перечня документов по БП Рабочая группа Владелец БП Перечень документов по БП 10 Формирование Формирование альбома альбома документов, используемых при документов по БП выполнении БП, и оформление его по утвержденной форме Рабочая группа Владелец БП Альбом документов по БП 11 Ввод в действие регламента Рабочая группа Владелец БП Утвержденный регламент БП Согласование, визирование, утверждение, ввод в действие регламента в соответствии с установленным в компании порядком Т а б л и ц а 4 .2 . П р и м е р ф о р м ы м а тр иц ы о т в е т с т в е н н о с т и по БП № Наименование операции или процедуры БП 1 2 3 И О У 0 У и 0 — сотрудник, ответственный за проведение и конечный результат работы, У — участвует в проведении работы, И — получает инф орм ацию о проведении БП (работы) и о его результатах. Список д олж ностны х лиц по штатному расписанию 1 — д олж ность 1,2 — долж ность 2,3 — долж ность 3. 4.6. Требования к анализу качества и эффективности работ по регламентации БП Эффективность выполнения работ по регламентации БП контролирует вы ш естоящ ий руководитель. Для контроля эффективности используются следу ющ ие показатели: • сроки разработки документа, регламентирующего БП (период времени от момента начала работ до момента предоставления владельцу на утверж дение регламентирующей документации по БП); • полнота созданной регламентирующей документации; • наличие вопросов по документу, не согласованных между участниками БП ; • возмож ность практического использования документа в полном объеме. 4Ш ' } нн*. ,-г %„■» Глава 4 Глава Качество моделирования Н е верю! К. Станиславский Моделирование бизнес-процессов (МБП) — одно из наиболее динамично разви вающихся направлений системного анализа. Но, несмотря на то что существует множество инструментов и методик МБП, нет единых стандартов их качества. Общая тенденция к возрастанию спроса на услуги консультантов в этой сфере обуславливается тем, что бизнес становится все более слож ны м , а у сл о вия его развития — неопределенными. С другой стороны , в рассматриваемой области (как, впрочем, и в лю бой другой области человеческой деятельности) наблюдается дефицит высококвалиф ицированны х специалистов. П оложение усугубляется еще и тем, что подготовить такого специалиста в стенах вуза не возможно: помимо теоретических знаний необходим опы т участия в проектах, приобретаемый годами. 5.1. Обеспечение качества моделирования Применимость методики моделирования бизнес-процессов в каж дом кон кретном случае зависит прежде всего от поставленных целей моделирования. Вопросы оценки применимости и выбора методики моделирования и инстру ментального средства, реализующ его иском ую методику, требую т отдельного разговора и выходят за рамки этой книги. Однако обоснованный выбор м ето дики и инструментария моделирования не единственное необходимое условие получения качественной модели. П оэтому разработка документа “ Соглашение о моделировании” является как бы “ настройкой” выбранной методики и ин струментария моделирования БП на конкретный проект моделирования. Большинство инструментальных средств типа САВЕ вообщ е не имею т в своем составе подсистемы, отвечающ ей за оценку качества модели. В остальны х (на пример, А Ш 8 Тоо1зе1;) проверяется только синтаксическая корректность модели (т.е. степень ее соответствия формальной логике). А ведь кроме оценки полученных моделей БП как результата процесса мо делирования необходимо такж е оценивать качество самого процесса моделиро вания. П оскольку моделирование БП — это, как правило, проект или совокуп ность проектов, то качество процесса моделирования оценивают по степени со ответствия общ епринятым стандартам управления проектами. Каким ж е образом мож но оценить работу по моделированию БП? Какие сущ е ствую т критерии качества моделирования? Вопросы эти очень важны и прежде всего для заказчиков моделирования. Больш инство консалтинговых компаний ориентируются на соответствие по строенных моделей документу, регламентирующему частные требования к мо делям (документ “ Соглашение о моделировании” ). Следует отметить, что все известные методы реорганизации БП тож е ниче го не говорят об их качестве, в лучш ем случае возмож на лишь идентификация некоторых общ их свойств “ хорош его” процесса, таких как естественность, по рядок выполнения его этапов, наличие нескольких версий и т.п., без каки х бы то ни было формальных критериев и метрик. ■ > я», г А оценивать модель БП необходимо тож е системно — и не только на адекват ность предметной области, но и по другим свойствам (взаимосвязанным): не противоречивости, достаточности для формирования требований к ИС, полноте, ясности и т.д. (рис. 5.1). Критерии качества моделирования визнес-проц< компании 1от15ость'дай” С001 н е т вне шналиям Ко? формирования требований к ИС ь м о »ели (й к л ю ч д м син*аксическ\ го л о Полно! а (вариант 110С 1Ь ) ЗЕ о НИ Ясность { понятность заказчику) Непротиворечивость (в заимол ИЯ шииость) ж Качес*во описании БП Сцепление* механизм взанмоченсчвии (взаимовлияния) межд> комнонешами БП Связное» ьмеханизм вн>1ренаей с*р\ к урн ой ор! ашгзации 1а кою компонент БП ЖЕ Методика оценки качества моделей БП позволяв!: 1. О ценивай качеспю моделей БП п\ |еч оценки степени соответсшия приведенным кртер п я м . 2. С 1рои 11011I11 ь. Iвозможные варнашы выполнения БП с )чею м возможностей для их улучшения. 3. Исключать из рассмотрения вариаш ы с неудовлетворительным качеством при моделировании БГ1. Рис. 5.1. Критерии качества моделирования 66 Глава 5 Оценка качества собственно БП, как известно ([1]), базируется на метриках сцепления и связности, которы е, соответственно, и переходят на их модели (см. рис. 5.1). А вот как и на скол ько все эти характеристики реально исполь зуются в работе отечественны х моделировщ иков БП? В опрос откры ты й! В нашей компании этом у уделяется первостепенное внимание, поскольку ка чественная модель позволит избежать возмож ны х отклонений в функциональ ном покрытии КИСУ и тем самым снизит себестоим ость проекта. Начинаем, конечно, с адекватности. Л юбая модель есть лишь отражение на ших знаний о реальном процессе. Мы говорим, что моделируем состояние про цесса “ Как есть” на объекте, т.е. описываем ту последовательность действий и преобразований (информации), которая реально происходит на объекте. Здесь и далее “ м ы ” — это системные аналитики, проводящ ие обследование и строя щие модели БП. Отсюда и первое ограничение — моделироваться (описыват ь ся) должны реально происходящие события, а не знания о них субъект ов на объ екте. Мы должны знать, что реально происходит, а не то, что кто-то думает, как оно происходит! Рассмотрим пример. Начальник производства не мож ет (!) описать процесс производства, так как он его себе только представляет, а на самом деле в деталях производство может немного (или много) отличаться от его представлений. Значит, для моде лирования мы должны пройти по всем точкам процесса от начала до конца, со бирая информацию от реальных участников собы тий. Как часто опрос начина ется и заканчивается именно начальником, мотивируя его выбранным уровнем декомпозиции процессов объекта? Далее. Что такое процесс? Упрощенно — это последовательность некоторых действий. Значит, мы долж ны фиксировать все (да, именно все!) возмож ные варианты развития собы тий. Это и есть полно та модели БП. Например, если клиент доволен предложенными условиями, то с ним заключается договор — на этом процедура заключения договора счита ется описанной. И все. А на самом деле забыли про очень важ ную вещь — про “клиент не доволен” . Что там недоволен — он просто взял и ушел к конкурен ту! Без комментариев! П оэтом у и необходима детальная проработка процесса со слов субъектов, его реально выполняющ их. Теперь сам субъект. Кто выполняет его функции на самом деле? Проверка по входам и выходам информации. Далее, каж дое действие оставляет информа ционный след. Значит каж дой операции модели должен бы ть сопоставлен до кумент, ее отраж ающ ий. Если нет бумаж ного подтверждения (а оно есть почти всегда), то прописы ваю тся действия по умолчанию. Это и есть достаточность описания БП для формирования требований к про ектируемой ИС и его ясность для заказчика. Далее, время. М ы живем в линейном мире и слово “ последовательность” отра жает большинство наш их действий. Записываем время выполнения или начала выполнения каж дого действия — получаем еще один механизм для проверки. Если интервалы пересекаются, то либо мы получили сведения о том, как ктото “думает, как процесс должен идти” , либо имеет место ветвление процесса, Качество моделирования 67 либо... и т.д. Все необходимо проверить и взаимоувязать! Ведь любая процедура всегда оставляет информационные следы, надо только их тщательно зафиксиро вать! Это и есть непротиворечивость модели БП. Когда речь заходит об описании внутренней организации ваш их БП (а об этом уж е написано очень много и достаточно хорош о), тут ж е встает вопрос о критериях его качественного описания — полноте, взаимосвязях между его бизнес-функциями (БФ) и, самое важное, его достаточности для подготовки тех нического задания на разработку проекта КИСУ. Для этих целей мож но с успе хом воспользоваться критериями теории модульного программирования, в част ности критериями сцепления и связности. Более того, сущ ествую т и методики достиж ения этих критериев, которые практически без изменения м огут быть использованы и для оптимизации ва ш их БП ([1]). При описании БП очень важно, чтобы составляющ ие его БФ были как мож но более независимы (критерий сцепления) и чтобы каж дая из них выполняла единственную, связанную с общей задачей, подзадачу (критерий связности) ([1]). Одним из способов оценки качества БП является анализ сцепления реализу ю щ их его БФ. Ф актически, сцепление представляет собой меру взаимозависи мости БФ. В хорошем БП сцепления должны быть минимизированы, т.е. функ ции долж ны быть слабо зависимыми (независимыми) настолько, насколько это возмож но. Ф актически понятие сцепления обобщ ает механизмы передачи пара метров меж ду компонентами и является лишь одним из критериев оценки каче ства разбиения БП на составные части: он оценивает, насколько хорош о входя щие в него БФ отделены друг от друга. Д ругим критерием оценки качества расчленения БП является критерий связности, контролирую щ ий, как сгруппированные в одной функции действия связаны друг с другом. Связность — это мера прочности соединения функцио нальных и информационных объектов внутри одной БФ. Размещение сильно связанных объектов в одной и той ж е функции уменьшает межфункциональные взаимосвязи и взаимовлияния. Сцепление и связность являются двумя взаимозависимыми метриками качества разбие ния процесса на части — связанность часто определяет качество ее сцепления с другими функциями. Помимо этих безусловных критериев вас должны еще интересовать вариатив ность, ясность, взаимоувязанность и достаточность полученных моделей (под робнее об этом речь пойдет далее). И вот тут на первый план выходит исполни тель отображ ения БП на модель. Это он должен знать про критерии качества БМ и обеспечивать их соответствие (а делают ли это другие консультанты?). Ведь лю бое СА8Е-средство — это только набор инструментов для описания, а описы вают БП конкретные аналитики. Глава 5 Рассмотрим отвлеченный пример. Вы приобрели руководство по строительству деревянно го дома — там подробно написано, как правильно махать топором и делать пазы для со единения бревен в венец сруба. Хотя очевидно, что если вы не плотник, то и дом у вас, ско рее всего, получится некачественный! Для построения качественного дома (модели) нужен именно плотник (практикующий консультант), а не просто человек с топором! Таким образом, после того как процесс моделирования будет завершен, н уж но проверить, “ водя пальцем заказчика” по схеме БП, что все процедуры описа ныполностью, нигде не возникает противоречий и заказчику все понятно. А как же консалтинговые компании доказывают адекватность модели процессу? Ведь им необходимо это делать, убеждая клиента принять результаты моделирования БП. Обычно (так называемый, “формальный подход” ) всех участников процесса просят посмотреть на модель и подписать ее. То есть каж ды й субъект, описан ный в модели, должен расписаться в том, что модель отраж ает то, что он гово рил, и процедура выполняется именно так. А налитик сядет с каж ды м субъек том, потыкает в модель пальцем и убедит того подписать ее. Общаясь со многими аналитиками других компаний, мож но прийти к неуте шительному выводу, что на деле никто не использует процедуры оценки каче ства модели (за исключением, мож ет бы ть, банальной проверки модели на син таксическую корректность в рамках среды моделирования). А ведь клиент мож ет подписать модель по двум причинам: • все понятно и правильно; • ничего не понятно, но подпишу, чтобы не подумали, что я не понимаю! И второе происходит, уж поверьте практикую щ ему консультанту, значитель но чаще! Ведь на каж дое: “ а вот тут....” заказчика ему покаж ут подпись другого субъекта, полученную точно таким ж е образом! И поэтому адекватной такую модель считать пока нельзя, даже несмотря на подпись владельца. А ведь для проверки БМ на адекватность сущ ествую т специальные методы (см.рис. 5.1).Так как же,все-таки,достичьвысокогокачестваБМ ?В стилизованном виде это показано на рис. 5.2. Для того чтобы модели были качественными, технология МБП нашей компа нии, например, решает такие задачи: • еще на стадии сбора информации системный архитектор следит и за каче ством (адекватностью, полнотой и т.п.) описания БП; • процедура независимого рецензирования БМ (демонстрация моделей сто роннему бизнес-аналитику, которы й понимает выбранные нотации); • процедура тестирования БМ на предмет ее достаточности для формиро вания требований к ИС (не тот процесс идеален, который полностью по крывает предметную область, а тот, который выполняет пост авлен ную цель понятным для разработчика ИС образом!). Качество моделирования 69 остижения качества моделирования Бизнес-процессов Наличие системного архитектора ( в проекте еще на стадии сбора информации он следит за качеством, адекватностью, полнотой и т.п. описания БП) 31 Существует процедура независимого рецензирования БМ сторонними бизнесаналитиками (включая функциональных специалистов заказчика) Ж Тестирование моделей БП направлено на поиск наиболее типичных для каждой ФО или подразделения ошибок при работе с информационными ресурсами (ошибок в н отк а х данных) Пре ни вращение с<тания информационных объектов (ИО) и/или их атрибутов, не иено.н.тм ьп в ча п.иейшеи дсягс (ьности Ж Обеспечение необходимою сос1ава БМ и дос1аючнос1и их описания для формирования необходимых {ребований к нроекп ируемой ИС Предотврашенне огсутствия необхо т ч о ю ИО либо его неполноты а/или его атрибутов Предотвращение дублирования ИО и/яли их атрибутов и, как слстствие, их неео) члеонанпоегь и про гиворечивоеть Рис 5.2. Методы достижения высокого качества моделирования Тестирование моделей БП направлено на поиск наиболее типичны х для каж дой компании ош ибок при работе с информационными ресурсами (ош ибок в по токах данных). Примерами таких ош ибок являю тся: • создание информационных объектов (ИО) и /ил и их атрибутов, не исполь зуемых в дальнейшей деятельности; • отсутствие либо неполнота ИО и /ил и их атрибутов; • дублирование ИО и/или их атрибутов и, как следствие, их несогласован ность и противоречивость и т.д. И только теперь, когда необходимый уровень качества отдельных БМ будет достигнут, мож но говорить о построении интегрированной (целостной) БМ ком пании (ИБМ), которая и будет положена в основу ТЗ на проектирование КИСУ! Техническое задание на разработку ИС — это прежде всего отражение моде ли бизнес-процесса на модель создания ИС, а не наоборот. Поэт ому сначала вы полняется описание БП, потом пост роение И БМ , и только потом формирова ние ТЗ на проектируемую ИС. Как это ни удивительно на первый взгляд (вслед ствие очевидности), но нарушение этого принципа — довольно распространен ная ошибка и исправить ее заказчикам обходится ой как дорого! ч В процессе накопления опыта моделирования, безусловно, возрастет роль референтных моделей бизнеса. Все более отчуж даясь от своих создателей, они постепенно превращаются в товар, производимый консалтинговой фирмой (в виде библиотек моделей по промышленным отраслям, вариантов конкретных БП и т.п.). Однако при их использовании в конкретной компании всегда необходимо про водить оценку их качества для данных конкретны х БП с использованием ком плекса метрик, показанных на рис. 5.2, а такж е выбирать адекватный инстру ментарий по их настройке на эти самые конкретные БП. Критерии, по которым в нашей компании определяется качество разработанных БМ, следующ ие: *<; • соответствие методологии и соглашению в целом; • соответствие критериям описания БП по связности и сцеплению; • соответствие нотациям инструментальной среды (если она используется); • непротиворечивость или взаимоувязанность; • ясность и понятность заказчику; • • полнота или вариативность; • достаточность для формирования требований к КИСУ. Подробнее содержание используемых критериев представлено табл. 5.2. |< - > х ч "I Качество моделирования нш. •• , \> 1 * г-')' ' ■ ' » * с ► г Таблица 5.2. Описание критериев качества БМ Критерии Содержание критерия Соответствие методологии и соглашению в целом ИБМ должна соответствовать архитектуре, приведенной в методике, а ее БМ, их объекты и связи между ними в цепочке добавленной стоимости должны быть представлены в соответствии с принятым соглашением Соответствие критериям описания БП по связности и сцеплению Модель БП должна: • представлять собой цепочку добавленной стоимости; • обладать внутренней связностью (механизм внутренней структурной организации потока работ); • обеспечивать внутреннее сцепление (механизм внутреннего взаимодействия объектов потока работ). Полнота (Вариативность) БП (или отдельная его процедура) должен содержать не только все реально выполняемые, но и все допустимые варианты действий (работ), событий и применяемых или используемых документов (и их статусов) Соответствие нотациям БМ должна соответствовать внутренней логике инструментального средства, т.е. должна быть проверена на синтаксическую и семантическую корректность языку выбранной нотации АК15 Ясность БМ должна быть полностью (по всем работам, событиям, документам, используемым интерфейсам и прикладным системам) понятна не только ее владельцу, но всем ее исполнителям! Непротиворечивость (взаимоувязанность) БМ должна быть согласована (взаимоувязана) со всеми другими необходимыми БМ по всем ее объектам: документам, событиям, работам, системам и т.д. Все используемые объекты должны быть описаны в соответствии с соглашением и находиться в единой базе инструментального средства. БМ обязательно должны иметь перекрестные ссылки на все модели, связанные с ее объектами (документами, организационными единицами, интерфейсами и прикладными системами) Достаточность БМ обязательно должны иметь в своем составе (во всех цепочках добавленной стоимости) все необходимые для функционирования разрабатываемой КИСУ информационные объекты (ИО), а их сумма — служить достаточной основой для формирования ТЗ на ее эскизный проект 5.2. Оптимизация БП и определение их показателей Глобальная цель любой науки состоит в том, чтобы свести самое удивит ельное к обычному. . , Э. Квейд Когда руководство компании, наконец, осознает, что управлять мож но толь ко тем, что м ож но измерить, начинается разработка показателей эффективности (ПЭ) ее БП. Причем ПЭ долж ны быть обязательно измеримы — ведь только циф 72 * "‘Л’’ Глава 5 ре можно доверять, поскольку все другие способы оценки имеют ярко выражен ный субъективный характер. Замечу, что в ПЭ иногда вкладывается какой-то таинственно-мистический смысл — бытует мнение, что это долж ны быть некие слож ные коэффициенты, разработать которые сама компания не в состоянии! На самом деле все значи тельно проще (рис. 5.3). Если посмотреть на дерево показателей на этом рисун ке, то ничего таинственного и слож ного в нем на поверку не окаж ется. Все пока затели достаточно просты и легко измеряемы. И любая осмысленная их комби нация тож е мож ет быть целесообразным ПЭ. Показатели Бизнес-процесса Рис. 5 3. Возможный набор показателей бизнес процесса 5.2.1. Подход к последующей оптимизации БП Схема подхода к процессу дальнейшей оптимизации описанных и регламен тированных БП компании заказчика показана на рис. 5.4. 5.2.2. Подход к разработке ССП Схема подхода к процессу разработки ССП на основе моделей БП ([14]) пока зана на рис. 5.5. Схема реализации ССП после создания репозитария БП с использованием м о дуля А Ш 8 В8С показана на рис. 5.6. Качество моделирования 73 Мониторинг и совершенствование БП Стандарт 130 9000 Разра8таарегля|[||»в Рис. 5.4. Схема подхода к процессу оптимизации БП — I” Разработка системы сбалансированных показателей (ССП) Г Бизнес-цели ] (ВЦ) Рис. 5.5. Схема подхода к процессу разработки ССП на основе взаимоувязанных моделей БП Система сбалансированных показателей (ССП) Администрирование репозитария БП в среде АКБ Рис. 5.6. Схема реализации ССП с использованием модуля АК18 В8С 5.3. Рекомендации по созданию БМ производственных Р процессов » При разработке моделей БП необходимо уделять особое внимание именно ин формационным потокам, отраж аю щ им все производственные и управленческие процессы на предприятии, а такж е способам обработки и анализа информации. Билл Гейтс в книге “ Бизнес со скоростью мысли” , говоря о реинжиниринге, считает необходимым создание “ нервной системы предприятия” , чтобы боль шинство обы чны х процессов на предприятии, как в ж ивом организме, проис ходило на уровне “ рефлексов” , оставляя голову свободной для творчества и ре акции во внештатной ситуации. Идея проектирования совершенно нового бизнес-процесса, полностью свобод ного от стереотипов и нынешних предпосылок, определяющ их его нынешнее со стояние, очень привлекательна. Н о в полном объеме она не используется почти никогда. Одна из основны х причин — неумение мыслить творчески и соответ ственно организовывать процесс работы. В больш инстве организаций мало л ю дей способны на это, так как этом у почти нигде не учат. Чаще всего при реинжиниринге применяются следующ ие механизмы твор чества. • Сходство — умение замечать связи меж ду вещами там, где и х раньше не наблюдалось. • Поиск альтернативных вариантов использования — способность обна руживать альтернативные варианты использования одной и той ж е вещи. • Поиск нескольких ответов — умение находить несколько разных отве тов на один и тот ж е вопрос. Рекомендуется найти несколько решений, в том числе самы х абсурдных и неочевидных. Достаточно часто проблема эффективно реш ается при обращении к той причине, которую раньше никто не замечал. • Поиск основны х причин — умение посмотреть на ситуацию под разными углами и найти в этом новые возмож ности. В ходе реинжиниринга рабочая команда должна использовать как можно больше методов творчества. Это и заимствование новых идей из других процес сов, на первый взгляд не связанных с рассматриваемым, и придумывание новых способов использования сущ ествую щ их ресурсов, и изобретение новых способов удовлетворения потребностей клиентов, и многое другое. Большой эффект дает анализ не только самоочевидных вариантов, но и таких, которые до этого никому в голову не приходили. При этом приходится бороться с существующими стереотипами и стремиться к выходу за установленные грани цы — в ходе реинжиниринга должны быть обязательно поставлены под вопрос ограничения, которые сущ ествуют в бизнес-процессах в настоящ ий момент. Качество моделирования Для стимулирования выработки идей при описании БП нуж но использовать следующ ие принципы. 1. В процесс должно быть вовлечено как мож но меньше людей. Э! 2. Клиент процесса по возмож ности должен сам участвовать в части процесса выполнения (например, в мониторинге показателей). 3. Обращение с поставщ иками должно происходить как с частью вашей компании (например, мож но попробовать обязать их выполнять ваши ре гламенты). 4. Обязательно создавайте несколько вариантов слож ны х процессов (напри мер, для сравнения их эффективности или управляемости). , 5. Уменьшайте число входов в процесс. • » 6. Централизуйте обмен информацией при наличии децентрализации подразделений его участников. 7. П остарайтесь проанализировать возмож ность вообщ е избавиться от этого процесса или отдать его другим компаниям на аутсорсинг. 5.4. БМ — мифы и реальность Знающие не говорят, говорящие не знают. 4 *4» Лао цзы Сегодня доминирующим в теории управления становится тезис о постоянном ускорении изменений в среде бизнеса. Например, Винод Хосла, человек, стоявший у колыбели компании 8ип МгсгозузЪетз, утверждает следующее: “ Мысль о том, что предпринимателям нужны подробные бизнес-планы, всегда казалась мне со мнительной, но сегодня в большинстве случаев она попросту абсурдна... Теперь курс приходится менять постоянно — нужно адаптироваться, а не планировать”. П оэтому ИТ должны рассматриваться в первую очередь как инструмент адап тации, и только во вторую — как инструмент выполнения планов. Неважно, в какой области вы работаете и какого размера ваша компания. Важно, чтобы она была развивающ ейся и растущей — ведь именно тогда ей нуж ны ИТ. Основная черта современности — динамичность. Чем больше динамичности, тем больш е требуется ИТ, ведь при росте компании всегда возникает дефицит ресурсов: денежных, лю дских, временных и пр. К аких-то ресурсов всегда будет не хватать. И именно ИТ позволяют покрыть этот дефицит — либо за счет опти мального планирования, либо за счет автоматизации процессов. Инструментом оптимального использования всех ресурсов компании служит разработка и внедрение КИСУ. 78 КИСУ — важная составляю щ ая современного крупного бизнеса. Невозможно представить себе устойчиво функционирующ ее корпоративное объединение безсредств поддержки его основных бизнес-функций в виде мощ ного центра ин формационных технологий. I Процесс создания слож ны х технических систем с заданными характеристи[ ками всегда был трудно выполнимым. В случае КИСУ проблемы усугубляю тся еще и взаимозависимостью проектных решений по бизнес — и ИТ-платформам. Значительная размерность таких задач требует и многоуровневой декомпози цииКИСУ как объекта проектирования. . Центральное место должно быть отведено именно модельному представлению объектов — как основе проектирования архитектур КИСУ, в том числе в свете динамики развития, обусловленной ускоренной сменой бизнес-платформ и бизнес-архитектур. Это обстоятельство объясняется тем, что в современных усло виях необходимы и важ ны не только оптимальное использование имею щ ихся ресурсов и повышение производительности труда, но и высокая степень управ ляемости, выраж ающ аяся в гибкости и бы строте реагирования на изменение внешней бизнес-ситуации при ориентации на постоянное активное взаимодей ствие с потребителями товаров и услуг (СКМ -технологии, са11-центры и т.д.). Именно поэтому в основу концептуального представления КИСУ должны быть положены как мож но более формализованные модели и методы анализа ; исинтеза проектных решений. Ибо конкурентоспособное функционирование современного предприятия возмож но только при условии постоянного стратеги ческого совершенствования его системы управления на базе именно модельного его представления с применением новейш их ИТ. Жизнеспособная система управления (в нашем случае это — КИСУ) должна : всегда в себе содержать модель самой себя\ Миф первый: КИСУ внедряется в связи с потребностями компании В реальности порядок внедрения чащ е определяется вовсе не планом, зави сящим от потребностей компании, а совсем другими факторами. • Пробивными способностями руководителей конкретны х подразделений предприятия. г • Тем, что внедряющая компания “ проникает” на предприятие через “определенное” подразделение. ,8Р • Возможностями “знакомы х” консультантов по конкретным модулям. Вот такая она, наша реальность. И приводит эта реальность к очень печальным результатам — по данным компании Ргше^аЪегЪоиееСоорегз, к 2001 году на Западе число неудачных вне дрений ИТ-систем класса ЕЕР достигло 28 % . В России точной статистики в §той области не ведется, но летом 2001 года, например, у БАР из 200 инсталля- . Качество моделирования ций программы К /3 работало, по подсчетам самого разработчика, 110. Очевидно, что понятие “ работало” еще ничего не говорит о степени решения реальных про изводственных задач — здесь дела обстоят еще хуж е. Вглядитесь в бесконечное пространство безответственности, созданное поставщи ками ПО, крупными консалтинговыми компаниями и корпоративным руковод ством. Прислушайтесь к тишине. Поставщики молчат о проданных приложени ях, которые не работают и не приносят прибыли. Консультанты по конфигурации крупных систем и системной интеграции скрывают свою причастность к неэф фективным решениям. Руководители компаний, купившие новое ПО для улуч шения деятельности, — эти, пожалуй, сидят тише всех. Они слишком злы, чтобы обсуждать плачевные результаты. , . ' . т А одной из основны х причин этого является отсутствие предварительно под готовленной (и, естественно, заранее продуманной) бизнес-модели деятельности компании — без нее на рынок за “ покупкой” ИТ-системы идти нельзя! Миф второй: для БМ важно правильно выбрать САЗЕ-средство моделирования Для описания БП чаще всего не используется вообщ е никаких СА8Е-средств, так как в подавляющем больш инстве очень сомнительна окупаемость затрат на их использование. И специфика нашей работы консультантов и внедренцев в том, что мы занимаемся всегда заказными, а не тиражными разработками, и поэтому использовать диаграммки в Угзю нам гораздо “ бюджетней” (ведь на этапе консалтинга еще не ясно, какое решение примет заказчик). Конечно, основная ниша СА8Е-инструментов — это проектирование именно больш их ИТ-систем. Но и здесь окупаемость от их использования мож ет быть достигнута только при условии: • достаточного финансирования, • правильной организации проекта, • наличия специально обученного персонала, • задания разумных сроков и т.д. А “ по ж изни” консультантам приходится чаще всего работать над так назы ваемыми “ экстремальными” проектами (в англоязычной литературе за такими проектами утвердилось название йеаШ тагсН — “смертельный марш” ). П оэтому в реальности при бизнес-моделировании нет никаких А Ш 8 ([2]) и ВР\ У т ([8]) — в лучшем случае это просто схемки, выполненные в У1зю, а чаще все го это вообще “ квадратики со стрелками”, нарисованные в М8 ДУогс! (рис. 5.7)! 80 Глава 5 85% В Никаких ШАК15 □ВР\ЛЛп □ Другие Рис. 5.7. Статистика использования САЗЕ-продуктов при бизнес-моделировании (по данным автора) Некоторая популярность В Р \У т (8 % ) связана вовсе не с его эффективнос тью, а с тем фактом, что он опирается на методологию ГОЕГ ([3]), которая при нята в качестве стандарта при построении процессной модели управления и к о торую рекомендует использовать другой популярный стандарт — 180 9001 ([4]). Сматериалами по подробному и детальному сравнению всех САЗЕ-продуктов можно ознакомиться в работах [9], [10], [11]. А здесь хотелось бы еще и еще раз отметить нецелесообразность сравнения от дельно взятых СА8Е-средств, поскольку ни одно из них не решает в целом все про блемы создания и сопровождения КИСУ. Это подтверждается также полным на бором критериев оценки и выбора, затрагивающих все этапы построения КИСУ. Корректно сравниваться могут комплексы методологически и технологически со гласованных инструментальных средств, которых пока не существует. ч На сегодняшний день наиболее развитым из всех поставляемых в России комплексов такого рода является комплекс технологий и инструментальных средств создания КИСУ — А Ш 8 . Окупаемость средств на его использование должна быть аккуратно просчитана заранее. Миф третий: БМ — дело рук персонала только ИТ-подразделения 1 Как правило, при внедрении КИСУ всегда появляю тся трудности в основном организационного плана: изменение структуры некоторых подразделений, лом ка принятых методов работы, встраивание вновь появивш ихся функций и т.д. Основные из них удается реш ить только тогда, когда руководить внедрением поручается одному из первых руководителей компании, наделенному соответ ствующими правами. Но принимать нужные решения он станет только тогда, когда поймет всю систему (что происходит не всегда — вот для этого и нуж ны консультанты!). Качество м оделирования 81 Именно поэтому внедрение таких больш их систем, как КИСУ, невозможно без соблюдения принципа “ Первого руководителя” (рис. 5.8). В реальности од ними только силами И Т-служ б не обойтись (когда на руководителей среднего звена уж е не действую т уговоры и убеждения). Когда за КИСУ отвечает ИТ- служба компании Когда в компании есть ИТ-директор Ответст венность за результаты внедрения ИТ-системы Рис. 5.8. Баланс полномочий и ответственности для успешного внедрения ИТ-систем Миф четвертый: БМ — это просто описание БП .* Да, зачастую описание БП решает много проблем. Мы уж е обсуж дали, что та кое БП — это, по сути, последовательность действий. Причем у начальника и его подчиненного представление об одном и том ж е бизнес-процессе бывает совер шенно разное. Например, часто руководитель компании находится во власти известного эф фекта “ проецирования” — стремления видеть качества собственной личности в других лю дях. Этот фактор усиливает иллюзии руководителя в отношении целеполагания и реальных действий исполнителей. Если учесть, что руководи тель организации не всегда имеет возмож ность (да и желание) анализировать приемы и инструменты, которые применяют исполнители, то феномен “ проеци рования” имеет тенденцию к усилению. И достиж ение цели, и высокая эффек тивность этого достиж ения воспринимается руководителем как подтверждение правильности выбранной им управленческой технологии. Однако ему часто со всем невдомек, что цели организации могут достигаться не благодаря, а вопреки его решениям именно “ несанкционированными” действиями исполнителей. П роцесс описания БП — его формализация — унифицирует и синхронизиру ет эти представления, что заметно сниж ает феномен “ проецирования” и позво ляет реш ить много подобных проблем. П оэтому вопрос разработки и моделиро вания БП при таком понимании проблемы чаще всего и завершается на стадии их описания. И вы хотите теперь автоматизировать весь ваш детально описан ный беспорядок? Это прямой путь к уж е отмеченному выше результату (см. ци тату из [2])! 1 В реальности собственно моделирование — это как раз то, что начинается именно после полного описания всех Б П — эт ой ест ь создание Интегрированной БМвсей компании, где все БП взаимоувязаны и оптимизированы (см. рис. 1.7). Мифпятый: имитационное моделирование БП позволит увеличить прибыль Любая база моделей будет только надводной частью айсберга всех БП, про текающих в организации. Есть сущ ности, просто не поддающиеся моделирова нию, но играющие важ ную роль в функционировании БП — меж личностные отношения, например, или распространенные в последнее время “ процедуры выбора” субподрядчиков для “легализации отката”, и еще многое другое — вы сами можете продолжить этот перечень. Реалии таковы, что еще никто в мире не создал полноценной завершенной , математической модели, которая бы эффективно “ работала” в “ ж ивом ” бизнесе. I Другими словами, в реальности стоимостной и временной анализ “ неж ивой” модели — это просто лабораторная работа в области математического моделиро вания, результаты которой все равно окаж утся далекими от реальности и могут привести только к неправильным решениям! Миф шестой и самый коварный: без БМ можно обойтись Все общие принципы построения инфраструктуры ИС давно и хорош о из вестны. Понятно, что должна быть компьютерная сеть, интегрированная с теле фонией, серверами, системой защ иты и подключением к 1п1егпе1;. Эти элементы ИТ-инфраструктуры устоялись, они более-менее унифицированы, да и произво дителей соответствую щ его оборудования не так уж много. Что такое ИТ-инфраструктура понятно и для консультанта, и для заказчика. А вот программная надстройка, т.е. собственно системы типа КИСУ — вот они действительно строятся по проекту, который должен иметь в своем основа нии результаты бизнес-моделирования (рис. 5.9). Следует отметить, что уж е само внедрение ИТ-инфраструктуры предприятия позволяет значительно автоматизировать его жизнь. Это происходит благодаря тому, что базовая ИТ-инфраструктура уж е включает в себч основные функции автоматизации: • единую файловую систему, • электронную почту, • элементарную систему планирования, • офисные программы. Качество моделирования ‘1 83 Бизнес-архитектура компании Функциональная структура Структура систем хранения и передачи данных Техническая архитектура используемых систем и ; аппаратная конфигурация приложении С и с 1 слппоя ИТ -а р хи те ктур а компании ....................... .......( ..........." .....1 ........ ' 3 .......... Функциональная архитектура КИСУ Рис. 5.9. Место и роль БМ при автоматизации производства и при раз работке КИСУ Когда все это грамотно объединено в корпоративной сети, уж е наблюдается значительный эффект. Инфраструктура сама по себе — очень полезная вещь. П оэтому до недавнего времени часто внедрялась только ИТ-инфраструктура — даж е без развитых программных систем автоматизации бизнес-процессов, где, очевидно, в бизнес-моделях не было никакой нужды. А вот КИСУ без БМ как раз не обойтись! Если решили обойтись — то еще раз внимательно перечитайте приведенную выше цитату из [7]! Миф седьмой: при БМ можно обойтись без консультантов Реальность уж е была абсолютно ясно показана — на рис. 3.1. 84 Глава 5 Глава Бизнес-структуры компании и КИСУ Внедрение корпоративной информационной системы управления компанией, как известно, затрагивает все ее ключевые бизнес-процессы. П оэтому взаимоот ношения важ нейш их бизнес-структур компании и ее информационных служ б заслуживают отдельного обсуж дения. 6.1. Роль и место СЮ в построении КИСУ Где ничего не положено — нечего и взять. Евангелие от Матфея. Если для компании информация и знания — это ключевой ресурс, источник стратегического преимущества, то планировать потребность в информации, ор ганизовывать ее добычу, переработку, накопление, создавать и развивать инфра структуру информационных потоков и поддерживать культуру комм уникаций должен один из высш их руководителей компании. Таким образом, это уж е не просто ИТ-проект, а бизнес-проект. И если его о т дать полностью на откуп И Т-службе или функциональному подразделению, биз нес-результаты такого проекта подвергаются серьезным рискам. Как минимум, после внедрения система не смож ет адекватно поддерживать все необходимые бизнес-процессы. В современной компании топ-менеджер по ИТ или СЫе^ 1п:Гогта1;юп ОШ сег (СЮ) — этот т о т , кто как раз и отвечает за правильную реализацию стратегии бизнеса через эффективную организацию информационных систем (рис. 1.10). СЮ имеет больш ое поле деятельности: автоматизация процессов управления всеми аспектами бизнеса — от систем управления производством до систем управленческой отчетности и управления знаниями. Многим директорам российских компаний аббревиатура “ СЮ” пока вообще ни о чем не говорит — на больш инстве предприятий эту роль де-факто выпол няет начальник ИТ-отдела, “отвечающ ий за компьютеры” (или “ зам. по прово дам” ). И только в наиболее продвинуты х компаниях, которые успели достаточно тесно пообщ аться с западными управленцами и начавших впитывать западные методы управления, уж е складывается понятие СЮ. СЮ — это интеллектуальный центр компании, связующ ее звено всех подраз делений. Именно он — профессиональный постановщ ик задач по интеграции и построению структур сквозны х БП компании, и именно он должен формиро вать требования к будущей КИСУ. П оэтому он должен иметь не только хорошие знания в области ИТ и предметной области, но и системное мышление и (обяза тельно!) опы т бизнес-моделирования (рис.6.1). .ич'п • I V - 'Н а ь й 7» \ / X *' \ / Измерение у д о в л е тв о X ре н но сти по тр е бите ля -К / Г % / < / " уX Л ‘ р0И«СС / X Проводщ моделирование БП Анализирует полно)у и 1 и Л С к 'К .1 1 ЦОС 1 1. И эффекнтноеи, КИСУ I ---Являсчся р>ководи гелем ироекIа внедрения КИСУ со ■ КИ О .............. Дяс1 оценку удовле1вореннос1и потреби имя реализованной КИСУ \на ииирич N Т ехническое задание на СМсГ (пГогшаНоп ОГНсег ( СЮ), или ПТ-лирекпор )1о юн-менеджер в современной компании, коюрый огвечае! *а правильную ^ реалилщит е»ра1енш бюиеса чере* )ффек1Н|{ц>н] орикииаиню информационных снаеад ,1 (> С 1 :Н (1 'Ш О С 1 Ь требовании# к КИСУ г \ I Проводи! обоснованный выбор класса и шпа информационной сне Iемы для реализации концепции КИСУ Гд 'ЯГ***, Рас. 6.1. Роль и место СЮ в проекте внедрения КИСУ Если ж е СЮ хорош о ориентируется в бизнес-процессах компании, является частью высшей управленческой команды и мож ет влиять на формирование стра тегии бизнеса, то он смож ет формировать такую информационную политику, кг.ЧУЛ’» ; Г*, «л- : 81 Глава 6 которая будет работать на бизнес, а не за счет бизнеса. В этом и заключается корень успеха проекта внедрения КИСУ. Решая проблемы каж дого из отделов, СЮ должен организовать и провести описание БП и последующее бизнес-моделирование (взаимоувязывание и со гласование информационных потоков) всей деятельности компании, поскольку ошибки при интеграции отдельных информационных решений в общ ую систему могут иметь очень дорогостоящ ие последствия. Именно результ ат бизнес-моде лирования и может, и должен (если “все правильно сделано”) предвосхитить большинство эксперт ных рекомендаций консультантов по внедрению КИСУ. В свою очередь, качество управленческого решения обеспечивается информа цией: ее наличием/отсутствием, достоверностью, оперативностью получения и об работки, возможностью анализа принимаемых решений. И оценка приобретаемой КИСУ именно с этой точки зрения является крайне важной задачей. Справиться с ней может только руководитель, который будет нести ответственность за реше ния, принимаемые на основе информации, накапливаемой в самой этой системе. Еще один важный аспект заключается в том, что внедрение управленческих информационных систем, как правило, связано с перестройкой многих процес сов в организации и тут на первое место выходит организация работ по бизнесмоделированию. А оценить все последствия этих работ зачастую слож но даже руководству компании, не говоря уж е о “ технарях” в ИТ-отделах. Поэтому, чтобы директор ИТ-от дела стал СЮ, он должен быть прежде всего специалистом во всех аспект ах бизнеса его компании, а не “ компью тер ным завхозом”, который думает лишь о покупке “ железа” определенной кон фигурации. Вот тогда он и будет нести ответственность за эффективность биз неса. А если он знаком только с процессом создания ИТ-систем, но не понимает организации всего бизнеса компании и не знает текущ ей стратегии его разви тия, то это наш типичный российский “ начальник И Т”, который совершенно не подходит для проекта разработки и внедрения КИСУ. Все это подтверждает и наш опыт — опыт компаний-консультантов ([12]). Снова вынужден повториться: реальные случаи, когда решение о разработке и внедрении КИСУ принимается продуманно и осознанно, к сож алению, более редки, чем случаи, когда решение о внедрении ИС определяется протекцией о т дельных “ заинтересованных” руководителей или возмож ностями “ знакомы х” консультантов (рис. 6.2). Мы, внедренцы, постоянно сталкиваемся с тем, что ИТ-менеджер, являю щийся руководителем проекта внедрения ИС со стороны заказчика, крайне ред ко обладает достаточной административной властью и необходимыми знаниями для того, чтобы принимать требуемые решения. Чаще всего это мальчик на по бегушках, без реальных полномочий. А ведь надо учиты вать, что проекты вне дрения информационных систем находятся на сты ке технологий и, собственно, бизнеса (см. рис. 1.3). И такая ситуация приводит к очень больш им рискам при внедрении КИСУ, которые, к больш ому и уж е вашему (поскольку заплатили за КИСУ именно вы — потребители) сож алению, часто реализуются! Бизнес-структуры компании и КИСУ 87 Причины появления серьезных внедрении КИСУ Роль СЮ де-факто исполняет начальник ИТ-одела, “ отвечающий только за компьютеры” Внедрение КИСУ затрагивает не все ключевые бизнес* процессы ( БП) внедрение КИСУ, как А правило, связано с < *-~— перестройкой ^ некоторых бизнес^ процессов СЮ должен иметь не яько хорошие знания а области ИТ и в сдметной области, но и системное мышление и обязан елыю опыт бизнсс-чоделирования Огсутсгвие описания бизнес - процессов »рои*аодствешшй деятельности Внедрение КИСУ определяется не потребностями компании, а “ интересами” отдельных руководителей подразделений Результат бизнесмоделирования должен предвосхитить нее рекомендации . консультантов по внедрению КИСУ После внедрения КИСУ сможет адекватно поддерживать не все ключевые бизнес-процессы ( БП) Рис. 6.2. Причины появления ошибок при внедрении КИСУ 6.2. Взаимосвязь КИСУ с СМК Б удущ ее за правильно организованными компаниями. Д жек Траут Функционирование систем менеджмента качества (СМК) в современных усло виях связано с постоянным ростом информации и преобразованием ресурсов та к ого объема, слож ности и неопределенности, который превышает возможности обы чны х информационных систем управления производством воспринимать, интерпретировать и адекватно использовать эти ресурсы в течение реально име ю щ егося времени. При вы соких темпах изменений окруж ающ ей среды (например, появление принципиально новых требований потребителей) скорость адаптации произ водства с помощ ью СМК становится недостаточной. В этом случае необходима трансформация производства (например, переход на другой вид продукции) и полное “ перепрограммирование” всех управляю щ их воздействий. 88 Вот почему во м ногих случаях высококачест венная продукция становится в определенный момент просто невыгодной. И в этом случае СМК оказывается нежизнеспособной ([12]). Мировой опыт показывает, что успеха достигают именно те предприятия, кото рые балансируют производственные, коммерческие и финансовые цели, т.е. рабо тают на повышение своего потенциала (качество потенциала компании — далее КПК). Уровень КПК (а это не что иное, как уровень развития его бизнес-процессов или, на западный манер, — ВР1, В и втезв Ргосезз 1тргоуегаеп1,) характеризует жизнеспособность предприятия ([12]), обеспечивая шанс получения прибыли в будущем (рис. 6.3). Совершенствоформирование Предвосхищение потребностей потребителе» ( Мировой класс), Соответствие скрытым потребностям потребителей Адаптация Ы1 к среде соотношение цена/качелво) О ти м тап ия ЬН (Хорошее соо! ношение иАна^начссгко) Когпро 1Ь Балансировка целен (Качество постоянное) Соответствие фактическим потребностям потребителей Соотегствие стандартам Хаос (Качество случайное) Рис. 6.3. Уровни развития КПК и место СМК по модели 180 9001 Уровень КПК “ Соответствие стандарту” подразумевает то качество продук ции, которое достиж им о на сущ ествую щ ем технологическом оборудовании предприятия. Таким образом, данный уровень качества продукции понимается как соответствие внутризаводскому стандарту. На предприятиях, организация бизнес-процессов которы х соответствует уровню “ Х аос” , качество продукции является случайной величиной и напрямую зависит от способностей отдель ных сотрудников. Качество продукции для КПК уровня “ Контроль” уж е явля ется постоянной величиной за счет того, что предприятие из “ черного ящ ика” превращается в “ прозрачную систему”, где налажен четкий производственный и управленческий учет и контроль. Бизнес-структуры компании и КИСУ 9 Уровень КПК “ Соответствие фактическим требованиям потребителей” опре деляется не только соответствием стандарту предприятия, но и удовлетворени ем эксплуатационных требований (потребностей потребителя). С этим уровнем КПК соотносятся “ Контроль” и “ Оптимизация” . Вот здесь как раз место СМК по модели 180 9001 — она обеспечивает уровень “ Контроль” и механизм перехода на уровень “ Оптимизация” . Для предприятия, соответствую щ его КПК уровню “ Контроль”, высокое ка-. чество продукции будет соответствовать и высокой цене на нее. Предприятие с КПК уровнем “ Оптимизация” характеризуется приемлемым соотношением цены и качества продукции. Уровень “ Соответствие скры ты м требованиям потребителей” подразумевает высокое качество продукции по низкой цене. Продукция данного уровня каче ства мож ет конкурировать с продукцией мировы х производителей. С данным уровнем соотносятся такие КПК-уровни, как “ Оптимизация” и “Адаптация”. Вот здесь, при переходе от третьего уровня к четвертому и далее, СМК по мо дели 180 9001 уж е ничем компании помочь не сможет. Последний уровень качества — “ Предвосхищение потребностей потребите лей” . Качество продукции данного уровня направлено на удовлетворение буду щего спроса. Этот уровень характерен для предприятий КПК уровня “ Мировой класс”. П оэтому только внедрение ИТ-системы именно ЕКР-класса мож но рас сматривать как обеспечение процесса достиж ения пятого уровня — т.е. значи тельного улучшения бизнес-процессов организации и управления предприяти ем (рис. 6.4). Для успеш ного внедрения ИТ-системы необходимо учитывать, что именно сотрудники компании м огут использовать или не использовать методики, зало женные в основу ИТ-системы. Для того чтобы люди прониклись данными ме тодиками, как раз необходимы (требуемые 180 9001) Политика и Цели в обла сти качества, и осознание всеми сотрудниками своего вклада в их достижение, и программы улучшения производства ([4]). Обеспечение регулярного исполь зования методик в рам ках ИТ-системы осущ ествляется как раз методами СМК (методы обеспечения качества, методы стимулирования качества, методы кон троля результатов по качеству). С другой стороны, использование ИТ-системы, охватывающей операционные процессы предприятия, позволяет формализовать данные процессы, т.е. создать и поддерживать в актуальном состоянии модель предприятия. Записи по качеству ф ормируются в ИТ-системе на регулярной основе. Таким образом, в СМК на предприятии с помощ ью ИТ-системы достигается обратная связь меж ду выдвигаемыми требованиями и конечными результатами их вы полнения, что и является сутью самой СМК. 5 ‘ Глава 6 \ Интеграция СМК и ЕКР-систем ы управления производством ркмеш качества Корректирующие действия Предупреждающие действия Рабочие инструкции Записи по качеству Корпоративная культура ( Политика, цели и понимание т о го , что качество забота каждого) Интранет Автоматизация управления документооборотом Автоматизация управления взаимоотношениями с потребителями ( СКМ ) Компьютеризированое проектирование ( САО/САПР) Информационные системы Рис. 6.4. Концепция интеграции систем управления компанией Из практики многих зарубеж ны х компаний мож но сделать вывод о том, что СМК, не интегрированная в сист ему управления бизнесом, может привести крассогласованию действий и даже быть вредна с точки зрения бизнеса. С использованием И Т-системы ЕКР-класса реш ается проблема естественной интеграции комплексного управления качеством в управление бизнесом. ' ИТ-система ЕКР-класса и СМК являются взаимодополняющими инструментами непрерыв ного улучшения бизнес-процессов. 1 -г} к -ы-и Бизнес-структуры компании и КИСУ еп ш ’>V 1 д. Вся наша многолетняя практическая работа по внедрению корпоративных ИС подтверждает вывод о том, что И Т-системы и СМК взаимно дополняют друг друга на пути достиж ения цели непрерывного совершенствования бизнес-процессов (см. рис. 6.4). Именно поэтому внедрение КИСУ ЕКР-класса является за дачей куда более важной для компании, поскольку она автоматически обеспечи вает и выж иваемость, и эффективное функционирование СМК. 6.3. Роль маркетинга в управлении компанией Я всегда стремлюсь не туда, где шайба находит ся сейчас, а туда, где она, скорее всего, окажется. Уэйн Гретцки Существует много различных вариантов определения маркетинга, которые рас крывают его сущность. Американская ассоциация маркетинга дает следующее определение: “Маркетинг представляет собой процесс планирования и воплощения замысла, ценообразования, продвижения и реализации идей, товаров и услуг по средством обмена, удовлетворяющего потребности отдельных лиц и организаций”. Сущность маркетинга в том, что он не только одно из важнейших направлений совершенствования управления производством и сбытом продукции, но и слож ный социально-экономический процесс, важной целью которого становится обе спечение наиболее полного удовлетворения потребностей и спроса покупателей. П оэтому маркетинг мож но определить еще и как способ вскрытия и исполь зования потребностей, совершенст вования и повыш ения качества продукции и услуг в соответствии с этими потребностями и обеспечения на этой основе достижения коммерческих целей предприятия. Важнейшей ж е новацией именно новой версии международного стандарта 180 9001:2000 стало требование измерения удовлетворенности потребителей. Согласно этим требованиям компания должна провести опрос потребителей, проанализировать их требования, а затем учесть их при разработке систем ка чества. Сущ ествует м нож ество способов поиска информации о том, как потре бители оценивают организацию, например: телефонные опросы, проводимые периодически или сразу после поставки продукции; анкетирование потребите лей; анонимные опросы потребителей; привлечение фирм, занимающ ихся мар кетинговы ми услугами; опросы ф окусны х групп потребителей. Таким образом, предприятию не достаточно просто выпускать продукцию, от вечаю щ ую требованиям государственных стандартов и другой нормативной до кументации (хотя это является обязательным). П оэтому особенно важную роль в системе качества играет процесс маркетинга — именно он должен определить, что означает “ качество” для конкретного предприятия на конкретном рынке. Глава 6 Ведь качество — это способность продукции (услуг) удовлетворять потребности потребителей. И для подтверждения того, что предприятие действительно работа еткачественно, оно должно измерять уровень удовлетворенности потребителей. В своей работе мы постоянно сталкиваемся с ситуацией, когда в разных ор ганизациях под словом “ маркетинг” понимают часто совершенно разные вещи. Для одних это продажа своего товара, другие под маркетингом понимают просто рекламу, для третьих это вообщ е что-то ненужное, например, какие-то дорого стоящие маркетинговые исследования, с результатами которы х люди не знают, как поступать. И далеко не во всех организациях есть подразделения или специ алист, занимающийся маркетингом (в каком бы то ни было виде). Что касается недавно созданных и малых предприятий, то там функции марке тинга выполняет, как правило, сам директор (в той мере, в какой он это понимает). Итак, маркетинг — это, по больш ому счету, ориентация предприятия на ры нок, умение улавливать его тенденции и использовать их, предлагать на рынок именно то, в чем есть потребность, и именно так, чтобы заинтересовать потреби теля. Если ж е соответствую щ ей потребности еще нет, маркетинг помогает эту потребность сформировать. Если попытаться представить маркетинг образно и кратко, то мож но сказать, что это “ клю ч к сердцу” клиентов (т.е. к их потребностям) — его место в про цессном ландшафте компании показано на рис. 6.5. Рис. 6.5. Процессный ландшафт современной компании Бизнес-структуры компании и КИСУ В недалеком будущ ем определяющ ую роль в экономике будет играть именно маркетинг, поскольку только измерение удовлетворенности потребителей явля ется залогом не столько получения и повышения прибыльности предприятий, сколько постоянного повышения качества продукта или услуг. Теперь рассмотрим вторую важ ную роль маркетинга — создание имиджа компании, поскольку ее хорош ая репутация имеет реальную рыночную цену. В нашей стране, по данным многих исследований, одним из реш аю щ их факторов при выборе и покупке чего-либо является рекомендация близких или “ автори тетны х” людей. И чем более высока репутация фирмы, тем больше вероятность того, что ее кто-либо порекомендует ваш ему потенциальному клиенту. Однако формирование имидж а — очень длительный процесс, вложения в имидж дают результаты не сразу. Здесь нельзя обойтись разовыми вложениями, важно по стоянное внимание к этому вопросу. И мидж складывается из огромного числа составляю щ их, в деле его формирования нет мелочей, ведь даж е то, как секре тарь отвечает по телефону, формирует образ компании в глазах клиента. Чтобы более полно представить значение маркетинга именно в управлении производством, необходимо обратиться к международным стандартам ([4]). В системе определения качества продукции, отвечающ ей требованиям между народных стандартов 180 серии 9000 и охватывающей все стадии “ жизненного цикла” продукции, именно маркетинг играет ведущ ую роль. Это как бы “замок”, который соединяет в непрерывный процесс весь жизненный цикл (Ж Ц) производства. В соответствии с требованиями международных стандар тов “жизненный цикл” продукции состоит из этапов, показанных на рис. 6.6. Следовательно, в целях соответствия международным стандартам, система управления лю бого предприятия должна строиться с учетом перечисленных этапов “ жизненного цикла” и ведущее место в системе управления должно быть отведено именно служ бам маркетинга. Однако маркетинг начинается совсем не там, где завершается производство. Напротив, при правильной постановке бизнеса характер и масштабы производ ства диктую тся именно маркетингом. 4 Не стоит начинать проектирование и разработку продукции, предварительно не изучив требований к ней потребителя. Эффективное использование производственных мощ ностей, нового высоко производительного автоматического оборудования и прогрессивной технологии такж е предопределяется именно маркетинговыми исследованиями. В рамках маркетинга разрабатывается и применяется система мер воздей ствия на рынок и потребительский спрос с учетом возмож ности получения при были за счет максимального удовлетворения запросов потребителей. А цели предприятия достигаю тся именно через оценку и удовлетворение требований потребителей — ведь это их желание купить наш товар или наши услуги при носит нам прибыль (см. рис. 6.5)! Рис. 6.6. Петля качества, или ЖЦ продукции в представлении стандарта 180 9001 Маркетинг не только создает условия для выхода на рынок, но и способствует закреплению позиций предприятия на рынке путем формирования его имид жа, расширению продаж и бы строму изменению характеристик продукции или услуг под влиянием технологических достиж ений и требований потребителя. Бизнес-структуры компании и КИСУ 95 Глава Ошибки бизнесмоделирования Наиболее важные для управления величины неизвест ны и неопределимы количественно. И .Голдрат Ошибки, возникающ ие в результате некорректного моделирования бизнеспроцессов, неверного выбора критериев их эффективности, стоят очень дорого. Практика БМд показывает, что все ошибки условно можно разделить на страте гические, управленческие и технические (рис. 7.1). Все эти ошибки “закладывают ся”, как правило, именно на начальных этапах процесса бизнес-моделирования. 7.1. Отсутствие четких целей и задач I Когда у компании нет корпоративной культуры (миссии, стратегических це лей и задач), попытки провести обособленное документирование отдельных на правлений бизнеса вызывают определенные проблемы. В случае, если бизнесархитектура не связана с миссией и стратегическими целями, возникает опас ность утраты логической целостности всей корпоративной системы. На практике это означает потерю механизмов контроля и управления эффек тивностью бизнеса. Построение ключевых индикаторов результативности (КР1) часто основывается исключительно на финансовых показателях компании. Вместо полной картины мы получаем частную оценку в финансовом аспекте. Документирование по принципу “ чтобы мож но было в лю бой момент посмо треть” приводит к построению текущ ей системной архитектуры, не имеющей связей с реальным бизнесом. Ф актически это мертвое знание, которое устарева ет при первых ж е изменениях. А Стратегические Ош ибки бизнес-моделирования V Управленческие -з О г Онл ю в и е четких целей и за адч жим^ При изменении г-у бизнее-иронессов ........ - ........... ....... ........................................ О тсхю ви е : 0 •О об\чения (> 1 С ) 1С1 ВИС При моделировании бизнес-процессов принимаются необоснованные решения -ЛйыйГГ.» Технические персонала Ж ответственны х гаи -------------- ----- Документ иро- ванне О 0 «с) ю тви с едино! о понимания В н е с е н и е в рам ках отдельного проекта Док\ хеш ирование пронеес .........^ К г1 ...... Лоск> гное использование Ме 1010.101 ни ... Ь, ............. и __ Несвязанные направления 1«к> мен 1 ировании Рис, 7.1. В и ды ош ибок в бизнес м оделировании в различных базах данных Неполная информация, использование которой м е т неадекватные модели бизнеспроцессов 7.2. Отсутствие ответственных лиц 1 Эта ош ибка связана с внедрением любой методологии моделирования. Выход прост: у проекта должен быть спонсор или, проще говоря, куратор, на уровне топ-менеджмента компании. Ч асто бывает так: “ Назначим ответствен ным того из нас, кто меньше всех загруж ен” , — решает руководство и... очень сильно ош ибается! Куратору проекта необходимо постоянно поддерживать его на самом высоком уровне. Но в одиночку спонсор ничего не сделает — нуж ны еще и исполнители, несущ ие прямую ответственность за проект. Как правило, в крупной компании в документировании участвую т несколь ко смежных подразделений. Они работают по нескольким направлениям: цели и стратегические задачи, продукты и услуги, организационная структура, биз нес-процессы, архитектура и информационные системы. Выполнить все эти зада чи за относительно короткое время возможно лишь в небольшой организации. 7.3. Отсутствие единого понимания (соглашения) В компании должны быть разработаны внутренние соглашения о моделиро вании и документировании. Наличие такого документа особенно важ но на на чальных этапах (см. приложение А). Соглашение необходимо еще по одной причине. Дело в том, что одну и ту ж е информацию можно документировать с помощ ью десятка различных моделей. Иногда это бывает полезно, чтобы отразить какие-то специфические аспекты бизнеса. Однако в любом случае особенности использования моделей и объектов должны быть зафиксированы в соглашении о моделировании. 7.4. Лоскутное использование методологии _ Эта ош ибка вызвана низким уровнем корпоративной культуры и неготовнос тью сотрудников к инновациям. Ведь любая методология изначально предпо лагает, что в документирование знаний должны быть вовлечены все подразде ления, поскольку никто не мож ет знать всех аспектов конкретного направления лучше работающ их на нем сотрудников. Ни для кого не секрет, что очень часто нормативные документы (регламент, инструкция, положение) сущ ествую т от дельно от реальных бизнес-процессов. Мне не раз приходилось наблюдать, как в достаточно крупны х компаниях продолжали формально действовать регламенты не только пятилетней, но даже двадцатилетней давности! Причем эта ситуация характерна главным образом именно для крупны х производств, где уровень комм уникаций меж ду структур ными подразделениями достаточно низок. В ситуации, когда документирование возложено на одно подразделение, оно оказывается в роли вечно “догоняющего”. Отсутствие синхронности в управлении на различных уровнях приводит к потере логической целостности всего бизнеса. Ошибки бизнес-моделирования 99 При таком подходе невозможно оценить уровень документирования бизне са в конкретный момент, отследить все риски, оценить эффективность, степень автоматизации и т.д. В результате руководители компании получают сведения только об отдельных частях своего бизнеса. 7.5. Внедрение в рамках отдельного проекта Часто приходится слыш ать ош ибочное мнение о том, что методологию биз нес-моделирования мож но полностью внедрить в рамках одного отдельно взя того проекта — например, при построении электронного фронт-офиса. Все не так просто, поскольку даже в рам ках этого мини-проекта необходимо проде лать практически все ш аги: определить цели и задачи, разработать продукто вый ряд, определить роли, функции ответственных лиц, построить структуру подразделения, описать бизнес-процессы, разработать структуру данных, спро ектировать архитектуру приложений и составить спецификации интерфейсов с бэк-офисными информационными системами. Основные трудности возникаю т обы чно на стадии согласования проектной документации со смеж ными подразделениями. Проблема в том, что часто их со трудники м огут или просто не знать методологии, или прикрывать этим свое не желание согласовывать соответствую щ ие документы. Но и это еще не все. Ошибка, о которой идет речь, приводит к разрыву между корпоративной архитектурой и информационными системами. Бизнес компа нии не стоит на месте, поэтому отсутствие синхронности в управлении на раз личны х уровнях (стратегия, тактика, оперативная работа) приводит к потере логической целостности всей деятельности. 7.6. Несвязанные направления документирования Весь положительный эффект от внедрения методологии БМ легко может быть перечеркнут в случае несвязанного документирования различных частей корпоративной архитектуры. Так, без увязки меж ду 1Т- и бизнес-архитектурой теряется практическая ценность этого знания. Когда ставится задача докумен тировать интегрированные знания, ее зачастую мож но реш ить только с исполь зованием методологии БМ. 7.7. Документирование в различных базах данных Недостаточно полное владение инструментами методологии БМ — большой круг ответственных лиц, страх перед потерей логической целостности моделей часто приводят к тому, что документирование различных направлений корпора тивной архитектуры разрабатывается в отдельных репозитариях. Это приводит к проблемам при синхронизации данных из различных репозитариев. 100 Глава 7 Например, в среде А Ш 8 знания о бизнес-процессах компании не просто визу ализируются в графическом виде, но и хранятся в базе данных. Таким образом обеспечивается непротиворечивость и возмож ность многократного использова ния данных и моделей бизнес-процессов. Кроме того, к объектам моделей мож но присоединять другие объекты , создавая ссы лочную базу (рис. 7.2). я*^ Модель организации ссылочной базы объектов бизнес- моделей | * Рис 7.2. Концепция организации ссылочной базы результатов бизнес моделирования Вся необходимая для дальнейшего создания СМК документация формирует ся в А Ш 8 как отчет, т.е. описания процессов для руководства по качеству созда ются непосредственно из моделей цепочек добавленной стоимости, разработан ных в АК18 Тоо1ве1. М етодологические и рабочие инструкции создаю тся на базе еЕРС-моделей. Именно поэтому наличие нескольких репозитариев приводит к значитель ным затратам и потере логической целостности корпоративной архитектуры. *» Ошибки бизнес-моделирования ’г 1> 1 ‘ ‘ •*<■» 4 101 7.8. Отсутствие обучения персонала М нимая “ простота” методологии иногда создает ошибочное представление о том, что для описания БП нет нуж ды в дополнительном обучении персонала. Действительно, например, методология А Ш 8 достаточно понятна и хорошо до кументирована, и поэтому создается впечатление, что для работы с методология ми БМ нет нуж ды в дополнительном обучении персонала. В качестве аргумента часто мож но слышать, что сотрудники сами обучаются использованию М8 \Уогс1 или М8 Ехсе1. Но М 8 т г й и М 8 Ехсе1 — всего лишь инструменты, которыми должен владеть каж дый сотрудник, начиная от президента и заканчивая секретарями. В основе этих инструментов никакая методология не лежит. А Ш 8 ж е в первую очередь яв ляется методологией, и только потом инструментом. Более того, в отличие от то го ж е 'УУогй, эта методология только формируется и еще не стала стандартной. 7.9. Документирование есть конечный процесс Документирование знаний о бизнесе не является конечным процессом. Нельзя ожидать того, что когда-нибудь все знания будут задокументированы, регла менты — разработаны, а логические структуры баз данных и архитектура при ложений — спроектированы. Рано или поздно возникает вопрос: “А что делать дальш е?” Ж изнь не стоит на месте. За время, пока проводится документирование текущей ситуации, бизнес уходит вперед, происходят изменения в организацион ной структуре предприятия, а программное обеспечение продолжает разрабаты ваться и модернизироваться. Другой вопрос, что на первоначальном этапе сбора и накопления знаний, воз мож но, потребуется больше ресурсов, чем впоследствии. П оэтому более актуален вопрос: “ Сколько мне нуж но специалистов для того, чтобы успешно провести до кументирование знаний?” . Это действительно важно, поскольку без достаточно го числа специалистов невозможно запустить процесс документирования. Как уж е отмечалось, на начальных этапах целесообразно привлекать внеш них консультантов. Очень важ но с первых шагов залож ить грамотные подходы к использованию методологии, создать правильную структуру хранилища. 7.10. Принятие необоснованных решений I члН л Анализируя собранную в процессе анкетирования и интервьюирования ин формацию, аналитик моделирует (рисует) бизнес-процессы. Представим себе си туацию, когда над одним и тем ж е проектом независимо друг от друга работают два аналитика. И пусть они работают на адаптацию и внедрение одной и той же системы. Более того, пусть они применяют одну и ту ж е методологию, а также одни и те ж е средства моделирования. Как вы думаете, совпадут ли модели соз данных ими процессов? Верится с трудом. 102 Глава 1 А теперь представим себе, что оба аналитика приходят к руководителю, при нимающему решения, в том числе и по поводу автоматизации, со своими моде лями. Первый естественный вопрос: почему они разные? Второй вопрос: какая модель правильная, какую выбрать для дальнейшего использования? А это означает, что сущ ествует вероятность принятия необоснованного решения. Л!*"' 7.11. Неполная информация по БП В процессе сбора информации о бизнес-процессах обы чно применяются две формы — анкетирование и интервьюирование. Анкетирование — вещь полезная. Но этот метод может рассматриваться толь ко в качестве метода сбора предварительной информации, которая есть только по вод для разговора, не более. У каждой компании своя специфика, нельзя в анкете предусмотреть все нюансы. П оэтому применение только этого метода не может дать полной информации о бизнес-процессах. При использовании этого метода возникает много вопросов. • Кто такие ключевые работники? • Как быть с не ключевыми? • Почему сущ ествует уверенность, что высшее руководство досконально знает все бизнес-процессы предприятия? Итак, первый вопрос в том, кого следует опросить. Напрашивается вывод: надо опрашивать всех сотрудников, участвующих в бизнес-процессе, хотя бы на уровне от дельных должностей. Однако если несколько человек имеют одинаковые должности, то кого из них выбрать? А как определить, кто в каком бизнес-процессе участвует? И еще очень интересный вопрос: с кого начать? А вдруг кого-то пропустим? Из сказанного следует, что выбор конкретных людей для проведения интер вью — вопрос весьма сложный. Если к нему подойти недостаточно серьезно, то, как обычно в такой ситуации, программисты потом будут “ бегать” к сотрудникам и выяснять недостающие детали. Только здесь есть один нюанс: получаемая ими информация фиксируется на бумажках, которые после использования чаще всего оказываются в урне. П оэтому заказчик и менеджер проекта со стороны внедренца узнают об изменениях в самую последнюю очередь, если вообще узнают. 7.12. Изменение требований При внедрении и разработке КИСУ надо учитывать тот факт, что первоначаль ные требования будут изменяться. Изменения связаны, прежде всего, с изменени ями запросов внешней среды, на которые компания как организационная система вынуждена реагировать изменениями внутри себя — с целью их удовлетворения. А как при этих изменениях синхронизируются уж е спроектированные БП? Об этом мы поговорим далее. Ошибки бизнес-моделирования 103 Глава О Бизнес-модели компании 8.1. Оптимальная модель СМК с использованием АК13 В се великие идеи описываются короткими словами. I Д ж ек Траут ■Введем понятие оптимальной модели сист емы качества — ОМСК ([12]). Под теимальностью здесь однозначно будем понимать получение запланированно горезультата при минимальной степени документирования, т.е. максимальную величину отношения “ Результаты\Степень документированности” (аналог всем известного отношения “ Цена\Качество” ). Для того чтобы получить такую оптимальную модель (далее ОМСК), рекомен дуется выстраивать работу по сценарию (или плану), приведенному на рис. 8.1. Необходимо отметить, что подобные работы всегда начинаются именно с целеполагания и описания стратегий достиж ения бизнес-задач. Далее следует спланировать действия по достиж ению поставленных целей (план достиж ения) иописать сущ ествую щ ий процессный ландшафт. И только затем следует определить необходимые конкретные показатели БП, ко торые будут показывать степень достижения поставленных целей — что и является основным посылом для выстраивания своих БП в состоянии “ как должно быть” ! | Это достигается декомпозицией основных показателей на структуру процесс' ного ландшафта с последующей соответствую щ ей детализацией БП и их пока зателей до уровня функциональных подразделений и, при необходимости, до уровня рабочих мест. С он я н и е п р оц ессн ою .ишдш»ф| а .» К Ц М о имированне всех БП ( К как п 'Пп.) Д екомпош ция показателей на стр\кт>р> процессного лащ ш аф та М о и шроканне вссх ЬП ( как ю «ано бы *1>) Ра^або»ка Радеабодка меюлшс* Доклмеш нровалне м е ю шки оиен» ^ ч о ш н о р ш п а и оц е V ноказа(елеи довлсчворешшс г «ннребщелеи ^ффекчивносш БП проведенных р або1 г с ои а н и е д о к у м е н т СМК Рис. 8.1. К он цеп ц ия сценария пост роения опт им альной сист ем ы качест ва {’’ Вопрос перехода от состояния “ как есть” в состояние “ как должно быть” всег да вызывает большие трудности — чем ж е надо руководствоваться, чтобы прове сти целесообразные изменения в структуре БП? На самом деле ничего сложной тут нет — при этом переходе, как минимум, в структуре БП необходимо выпол нить следующее. | • Обеспечить мониторинг всех выстроенных показателей (контрольные точки измерения их метрик). г и • Устранить искажения в структуре БП (дублирование, несогласованное?! входов и выходов, лишние информационные объекты и т.д.). • Учесть требования процессного подхода — контроль, анализ, корректи рую щ ие и предупреж дающ ие действия ([1]). }; Последнее достигается коррекцией описания БП, которая должна учест уточняю щ ие и предупреж дающ ие действия, либо в виде сценариев устранени и предупреждения возникновения отклонений от нормального хода БП или ег процедуры (см. приложение А ), либо в виде отдельных процедур управления о: клонениями, проблемами и рисками. После этого уж е мож но заняться выбором методики оценки удовлетворены! сти потребителей — это приведет к возникновению еще нескольких необход: м ы х показателей. И наконец, настало время определить регламент мониторинг и последующ ей оценки всех ваш их показателей. Для всех этих целей как рг и подходит среда А Ш 8 ([2]). 106 Глава И вот только после этого мож но приступать к созданию единого пакета не обходимых для достиж ения ваш их целей регламентов — документированию именно вашей ОМСК! Вся требуемая для дальнейшего создания СМК докумен тация формируется в А Ш 8 как отчет, т.е. описания процессов для руководства покачеству создаю тся непосредственно из моделей цепочек добавленной стоим о сти, разработанных в АК18 Тоо1зе1;. М етодологические, рабочие и должностные инструкции создаю тся на базе еЕРС-моделей. Состав и структура полученной в результате документации такой ОМСК по отношению к модели 180 9001 представлена на рис. 8.2. Рис. 8.2. Состав и структура ОМСК по отношению к модели 1 8 0 9001 * ОМСК будет иметь значительно меньш ую документированность, однако эф фективность ее восприятия компенсируется наглядностью схем БП и процедур (лучше один раз увидеть, чем сто раз прочитать), тем самым она будет доступна всему персоналу (рис. 8.31). В данном случае концепция ОМСК целиком и пол ностью отражает лозунг: “ Эффективность — в упрощ ении!” . А степень воспри нимаемости здесь имеет очень важное значение — так уж устроена человеческая I психика: хорошо мы делаем только то, что хорош о понимаем! I На этомрисунке для сравнения приведены данные и для модели С М М — степень воспринимаемо стисистемы всегда обратно пропорциональна количеству описывающих ее регламентов! Бизнес-модели компании 107 В тож е время эффективность ОМСК будет, как минимум, на том ж е уровне, по скольку она менее “ забюрокрачена” и более понимаема и, значит, более восприни маема как конкретное руководство именно к практическим действиям (рис. 8.42), В данном случае концепция ОМСК может дать даже больший эффект чем пресло вутая модель 180 9001, поскольку она более доступна для понимания! Рис. 8.3. Экспертная оценка зависимости степени понимания от степени документированности ш о_ 5 «ь 5 X Л Ф с * >* Ь Ф 6 о о х * 1 ю Э о о.° * *я ч смм ( 5 уровень) 150 9001 > 8 Оптимальная к- а. модель СК оо. ^ о 5 ш 5 с гпа Степень документированности Рис. 8.4. Экспертная оценка зависимости вероят ности достижения результатов от степени доку ментированности Для сравнения приведены данные и для модели С М М — степень достижения результатов т этой модели считается максимальной, но при этом она содержит неизмеримо большее колит ство необходимых регламентов' 108 •=» Глава 8 Конечно, сертификат 180 9001 на такую ОМСК вы сразу не получите. ; Но! Вам легко и быстро (за 1-2 месяца) мож но будет формально достроить ее (под готовить необходимые для сертификации текстовые документы) до требований 180 9001 — ведь основные (и, безусловно, самые трудоемкие) “ правильные” тре бования этого стандарта у вас уж е выполнены (процессный подход, показатели достижения целей и их мониторинг). Более того, именно это ядро СМК (которое и описывает ОМСК) определяет собственно эффективность управления качеством, а вовсе не наличие тексто вогодокумента “ Р уководство по качеству”, которое вы теперь легко смож ете на писать и сами! В заключении этого раздела полезно будет дать графическое описание всего пути вашей компании к достиж ению поставленных вами целей — оно представ|ленонарис. 8.5. Процессный ландшафт достижения целей в области качества К тз на ИС \ / Сонсультанты г Ч Внедрение у ИС Персонал [ а I Консультанты' Ра фаСннка и внедрение ССП Персонал 4 Бизнесплан Цели и стратегии 111оя^льгантаТ М о (е.ш роваиие Руководство по качеству Руководство Бизнес-модели компании 169 8.2. Модульный вариант бизнес-модели компании М ноголетняя практика работы по созданию СМК в различных компани я х привела меня к мысли об эффективности создания м одульной структуры СМК — МСМК. Суть модульной структуры заключается в создании так называемых бизнес моделей каж дого подразделения, участвую щ его в обеспечении качества про изводственной деятельности — БМП (БМ подразделения). БМП — это как бы паспорт подразделения (рис. 8.6), в котором содерж ится вся необходимая для функционирования СМК информация: Процесс управления подразделением Матрица Постановка задач V Карты процессов. Описание входов и выходов ответственности Дерево задач подразделения Их декомпозиция на : отдел, сектор, группа, рабочие места Диаграмма информационных потоков И Структура подразделения г у отдел Показатели качества сектор Аиализнеобходаш Отчет СК: “Анализ СМК’ К “ 1 А группа 1 рабочие места Анализ необходимых регламентов / Нормативная документация и профессий наяьные инструкции * Рис. 8.6. Структура бизнес модели подразделения функции и решаемые задачи; структура (штатное расписание); показатели качества или эффективности его работы и их метрики; диаграмма информационных потоков; описание БП его деятельности (диаграммы БП); перечень нормативных документов (регулирую щ их эту деятельность); перечень поставщ иков и потребителей работ подразделения; 110 К 'Ж Ь ' М О Глава! • матрица ответственности персонала по всем функциям подразделения; • план достиж ения целей в области качества; • план улучшения работы в подразделении. * «*ч-м-.- « « ' >* -«-« * Методика, рекомендуемая к использованию для подготовки и сбора даннь х при разработке БМП, показана на рис. 8.7. Предлагаемая методика обеспечивает: • наиболее эффективную для управления изменениями модульную струк туру СМК; • актуализацию регламентов и схем бизнес-процессов на уровне их непо средственных участников и исполнителей; • актуализацию необходимости информационных объектов и их потоков меж ду подразделениями; • распределение ответственности внутри самих подразделений без бю ро кратических долж ностны х инструкций; • планирование достиж ения целей и улучшение деятельности непосред ственно в самих подразделениях (а не сверху); • необходимую для достиж ения целей в области качества детализацию основных показателей компании на уровень его подразделений; • оперативный внутренний мониторинг показателей качества работы каж дого подразделения компании. Задачи, решаемые подразде лением Задачи Выходные результаты деятельности Бизнеспроцессы компании Функции Критерии выполни мости Информаци онные потоки Потребители результатов Метрики результатов Потребители Методика сбора данных при пос!роении бизнес-модели подразделении Бизнес-модель подразделения_______ ......'"'Диаграмма' информационных потоков Описание участия подразделения в БП компании Рис. 8.7. Методика сбора данных для разработки бизнес-модели подразделения Бизнес-модели компании М1 Полученная таким образом модульная структура СМК имеет следующ ие пре имущ ества: • процесс управления изменениями проходит внутри подразделения (СК только контролирует его наличие); • механизм взаимосвязывания и согласования входов и выходов БП стано вится более эффективным; • обеспечивается получение более достоверны х значений показателей (су щ ествует заинтересованность самих исполнителей показать свою работу). « 112 ‘О' *• - I Н'ъг Глава Подведем итоги 9.1. Так как же правильно обустроить компанию? Системное содержание концепции управления качеством мож но проиллю стрировать с помощ ью стилизованной схемы ([12]), представленной на рис. 9.1. В табл. 9.1 приведены шаги правильной организации современной “ качествен ной” компании (КК) — в соответствии с системным содержанием концепции управления компанией, представленной на этой схеме. Таблица 9.1. М а тр и ц а “ о б у с т р о й с т в а к о м п а н и и ” №шага Что должно быть сделано, разработано и (или) внедрено Статус Комментарий 1 Разработан бизнес-план с четким указанием целей, их ключевых показателей и выбранных стратегий их достижения Необходимо Внедрение управления по целям позволяет сфокусировать КК и весь персонал компании недостижение поставленных целей 2 Построена путем бизнес- моделирования и оптимизирована интеграционная бизнесмодель (БМ) компании, содержащая необходимое для достижения целей число взаимоувязанных бизнеспроцессов (БП) Необходимо Внедрение процессного подхода предусматривает проведение моделирования БП (состояние “ Как есть” ) и их оптимизацию (состояние “Должно быть” ) Эта первая технологическая составляющая КК должна постоянно актуализироваться и “ подстраиваться” для достижения целей ' Регл.» '>енгы прс обе* ка сов »ения ша сод,еР*с< ание к»Нц, епЧии У,1Ра влен,и& Ком,пани ей Окончание табл. 9.1 №шага Что должно быть сделано, разработано и (или) внедрено Статус Комментарий 3 Разработана и внедрена система сбалансированных показателей (СПП) всех БП Желательно “ Управлять можно только тем, что можно измерить” — этот лозунг означает постоянный мониторинг ключевых , показателей деятельности Это вторая технологическая составляющая, которая позволяет проводить “ тонкую настройку” КК на достижение поставленных целей 4 Внедрена корпоративная информационная система управления (КИСУ) Желательно Среда корпоративной культуры, обеспечивающей: • принятие решений на основе объективных данных, • эффективные внутренние коммуникации, • управление знаниями персонала 5 Внедрена система менеджмента качества (СМК) по выбранной модели (150 9001, СММ и т.п.) Необходимо Ориентация на внутреннего и внешнего потребителя и управление БП. Измерение удовлетворенности персонала (внутренний потребитель СМК) — надежный индикатор состояния (“здоровья” ) КК 6 Построена и постоянно Необходимо развивается система мотивации персонала на достижение запланированных результатов (целей) Нравственно-надежный персонал — это не только необходимый фундамент СМК, но и фундамент для строительства всего “здания" КК ; Рис. 9.2 демонстрирует, из чего складывается понятие “ Качество ком пании” ! ([12]) и какое влияние на него имею т СМК и информационная система управ ления (КИСУ). В области общ его управления качеством (ТОМ) сущ ествует уж е несколько вполне самодостаточных моделей организации производственной деятельности, направленных на повышение ее эффективности — их взаимосвязь с СМК по оценке автора [12] приведена на рис. 9.3. Из этого рисунка видно, что внедрение СМК ([4]) успеш но реализует и модель бережливого производства ([13]), и управления по целям ([14]), и оптимизации | бизнеса ([1]). Тем самым она является основой для внедрения самой привлекательной с точки зрения понимания персонала модели “ 20 ключей” , известной еще как “ Практическая программа революционных преобразований на пред приятии ” ([15])! Для дальнейшего анализа степени взаимосвязанности упом януты х моделей попробуем представить модель технологического развития компании по пути 115 организации эффективного производства — по двум основным направлениям (векторам) СМК (рис. 9.4). Приведенная модель наглядно иллюстрирует назна чение и влияние процессов управления и выстраивания (моделирования) бизне са на эффективность СМК. Кроме того, она раскрывает взаимовлияние и степень их вклада в развитие собственно эффективного производства. Что ж е представляет собой новая модель “ 20 ключей” ? Прежде всего это ин струмент для оценки именно эффективности работы компании, включающий еще и методологию оценки проводимых улучшений и усовершенствований. Это своеобразный бенчмаркинговый инструмент, при помощи которого процесс анализа и последующ ей оценки эффективности работы компании существенно упрощ ается. Рис. 9.2. Концепция понятия “Качество компании” с учетом влияния СМК и КИСУ -тх 1 ^ ,- 0 <■ ' 116 Глава 9 Рис. 9 3. Концепция взаимосвязи моделей организации произ водственной деятельности, направленных на повышение ее эффективности Согласно этой системе ([14]), компания оценивает собственную организа цию по 20 ключам, каж ды й из которы х — фактор, имеющ ий критическое зна чение для ее функционирования. Оценка выполняется по 5-балльной системе. Посредством определения, на каком уровне компания находится по к аж дом у из 20 ключей, идентифицируются ее слабые места. Как показывает практика, ор ганизации, внедряющие эту систему, обы чно обнаруживают, что из максималь но возможных 100 очков (20 ключей х 5 баллов), они реально не достигаю т и 50. После этого компания реализует корректирующ ие действия по достиж ению эф фективности в выявленных направлениях. Подведем итоги 117 Рис. 9.4. Модель технологического развития компании по двум векторам системы ка чества: обеспечение и улучшение О собенностью модели “ 20 ключей” является то, что она не просто представ ляет совокупность л учш и х мероприятий и методов по усовершенствованию, а обеспечивает их интеграцию в одно взаимосвязанное целое. Результатом такой интеграции является эффект синергии: 20 ключей настолько тесно взаимосвя заны, что усовершенствование в одном ключе автоматически приводит к усо вершенствованию в остальны х девятнадцати. Основные принципы внедрения “ Практической программы революционных преобразований на предприятии” представлены на диаграмме взаимосвязей 20 ключей, показанной на рис. 9.5. ' •}' и > / ГЛ л г' * I ив * -» » ^ к Щ а 'Н ч и . '• <1 * 1 - > 4 Х * М 5 V* М '< "ч ' •* Глава 9 А ■ Рис. 9.5.Диаграмма модели методики “20 ключей” г а» Модель “ 20 ключей” или “ Практическая программа революции факторов” помогает компании направить свои силы именно в нужное русло: управлять изменениями, необходимыми для достиж ения стратегических целей бизнеса и сохранения конкурентоспособности на рынке, а такж е постоянно совершенство вать систему управления. При этом практическая методология улучшения всех факторов, имеющ их критическое значение для работы компании, обеспечивает достиж ение трех главных показателей эффективности ведения бизнеса: “Лучше, Быстрее, Дешевле” (см. рис. 9.5). Что касается конкретно внедрения системы “ 20 ключей” , то единого метода не сущ ествует, да и не мож ет сущ ествовать: приоритетность и методы улучше ния этих ключей компания в каж дой конкретной ситуации всегда определяет самостоятельно. Реализация больш инства ключей происходит при внедрении именно процесс ного управления, а именно при совершенствовании бизнес-процессов (БП) ком пании. Очевидно, что к преобразованиям и практическим действиям по улучше нию процессов нас подталкивает уж е сам рынок — нововведения конкурентов, изменение восприятия и ож иданий потребителей, технологические изменения. Для тех, кто отвечает за процесс, трудность заключается в определении именно конкретны х изменений и степени и х радикальности. Необходимость не которы х изменений в процессах мож ет стать очевидной сразу, другие потребуют больш их усилий, времени и ресурсов на их определение, анализ и осознание. Практика оптимизации бизнеса клиентов позволяет систематизировать эти ра боты и представить их совокупность в виде процесса улучшения БП, представ ленного на рис. 9.6. Обычно руководство, занятое, как правило, прибылью, издержками и т.п., решает проблему конфигурации управления самым простым, очевидным и, следовательно, неправильным способом — все замыкает на себя через тради ционные иерархические структуры , с недостатками которы х не в состоянии справиться никакое “делегирование полномочий” , и называет это управлением или еще хуж е: менеджментом. Не имея возмож ности заниматься совершенство ванием управления, руководство не “делегирует” эту функцию кому-либо, пу ская на самотек выполнение этой важнейшей — и главной для себя — функции успеш ного решения триединой задачи компании. На рис. 9.7 в стилизованном виде представлена модель успеш ного развития компании при помощи решения триединой задачи: управления персоналом, производством и качеством ([12]). Почему я заостряю на этом внимание? Да потому, что теперь очень часто в боль шинстве компаний “самой главной фигурой” бизнеса является финансовый ди ректор (или главбух) — лишь потому, что он “ распределяет” результат бизнеса. Но обеспечивают и “увеличивают” результат совсем другие фигуры (см. рис. 9.7). И как правило, их реальное значение для эффективности и развития бизнеса всег да незаслуженно остается в тени! Вот здесь и уместно будет вспомнить про сбалан сированную по всем важным факторам и направлениям модель “ 20 ключей” ([15])! 120 Глава 9 Концепция действии в процессе чл> чтения БП Моче (ъ процесса как т ь: посгаш ци кв-то |Мироцесе-выте т - по греби т т (АЧ 14 ( *<ляа ф ункционирования процесса ( ПИСИК НИ Ро>льтатм, характера юшие те к\щ е е со л о м ите качес * на функционирования процесса Ж Д анные. Данные, \т но ре<ллмитт. 110Ш0.1НИШ1НС чарак ( ери *> книне мнение (нмребшеля « качестве прнцесеа сравни и» протекание т а п т нчны% процессов в нашей и иш ольпем ы л 1р>* ич нроцеид при реа?и;ацин 1ЗД1НШ О ор 1 аки м ниич «нЯ тшш |» щяш» Ъштш I IIIIIшшIмм!|>»!|Ц1и1и«|I С писек проб 1см. иоишклиицич при рсали шнии « и н е ю иршиссд з С писок г иошимкмьны х решения М одель ироцеса к а к долж но б ы и . ( I О ВЕ ) I” А и а .ш ( «игра 1ЙМ — .■...... ■.. . , | -___ I чЦ* н исок иеооуо ы \ I ж зго ю С$ ш он п добю ш м ы нгмененин (пменешш 0 |ч с1 ко проек!> >.1>чикчти Ы 1 Рис. 9.6. Концепция действий в процессе оптимизации бизнес процессов Подведем итоги 121 Рис. 9.7. Модель решения триединой задачи: управления пер соналом, производством и качеством А насколько “ качественным” м ож ет быть управление, ориентированное только на оценку финансовых потоков, баланс, бю дж ет и другую чисто финансо вую информацию? Для аналогии предлагаю сравнить такое управление с игрой в футбол, когда игроки играют, нисколько не обращ ая внимания на мяч, а орич 122 \ ’г 4 1 ‘ПИ*) * * ( 1 1 » М 4 А>Н ' V и- Глава 9 ентируясь только на табло стадиона. Именно поэтому, наблюдая, как проходит, например, совет директоров компании (или заседание руководства в какой-то другой форме), я очень часто вспоминаю басню Крылова “ Свинья под дубом ” . Теперь можно сделать вывод, что и концепция оптимизации бизнеса (см. рис. 9.6), и концепция постановки задачи управления (см. рис. 9.7), и концеп ция достижения качества самой компании (см. рис. 9.2) при внедрении и дальней шем совершенствовании СМК — это все и есть конкретные способы достижения верхнего уровня оценки реализации всех 20 ключей! I и ’> 9.2. Вместо заключения М ы никогда не сможем изменить направление ветра. Н о в нашей власти поставить нужные паруса. „ | Лао Ц зы Если вы при моделировании ваш его бизнеса воспользовались изложенны ми выше рекомендациями и избежали ош ибок (внимательно изучите рис. 6.2), в результате вы получите нуж ны й именно вам проект И Т-архитектуры именно вашей компании. • Корпоративные цели и стратегии определят основные направления ее раз вития и поставят долгосрочные цели и задачи. • Бизнес-архитектура на основании стратегий развития и долгосрочных бизнес-целей определит необходимую именно вам: . структуру БП; | • информационные и материальные потоки; • а такж е поддерж ивающ ую их организационно-штатную структуру. , Системная ж е архитектура, отобразив все эти бизнес-требования, определит совокупность технологических и технических решений для обеспечения инфор мационной поддержки вашей деятельности (рис. 9.8). Вот теперь, когда вы поняли, что нужно именно вам, мож ете смело идти на рынок и покупать И Т-систему для вашей КИСУ! В последнее время некоторые компании активно развиваются за счет “ тира жирования” бизнеса — открытия филиалов или дочерних структур на удален ных рынках. В том случае, когда компания выбирает такую стратегию развития, становится еще более целесообразным тщательно проанализировать работу уж е действующих подразделений, изучить их бизнес-процессы и зафиксировать все это в виде стандарта работ — “ж ивы х” инструкций и регламентов БП, т.е. в виде хорошо нам теперь знакомой бизнес-модели компании. Подведем итоги 123 функциональная структура приложений Структура систем хранения и передачи данных Базы данных и хранилища данных Прикладные системы, поддерживающие исполнение БП Системы управления базами данных или хранилищами данных Интерфейсы I взаимодействия 1рикладных си *, между со б о й » I внешними , системами, 1источниками и потребителя данных Техническая исп :,зу* аппа) на? рш архите гра , 1Х сис «и нфигу^ ЦИЯ <ении П Сетевая архитектура г Аппаратные средства вычислительной техники и компьютерное оборудование Локальные и территориальные вычислительные сети Коммуникационные протоколы сервисы и системы адресации Операционные и управляющие системы 1 Средства и | методы разработки I во» ! приложений! Правила и средства санкционирования доступа к данным ; I Планы по обеспечению бесперебойной работы сетей и аппаратуры в условия* чрезвычайных обстоятельств Рис. 9.8. Концепция построения системной И Т архитектуры компании И еще. Наличие типовой бизнес-модели позволяет открывать новые филиалы по ти повой схеме: приехал на место, набрал персонал, развернул чемоданчик с бизнесмоделью, вручил специалистам все необходимое для их деятельности — и бизнес пошел! Необходимо еще раз отметить, что КИСУ является важнейшей составляю щей для последующего построения эффективной СМК (см. рис. 8.5). Именно по этому, внедряя автоматизированные системы типа КИСУ, описывая и глубоко вникая при этом в бизнес-процессы клиента, стремясь оптимизировать их, мы, по существу, всегда ведем заказчика к последующ ему созданию СМК. П оэтому после внедрения КИСУ ваша компания уж е мож ет приступать (при наличии внутреннего или внешнего побудительного мотива) к созданию СМК (рис. 9.9). | Модель целей компании Модель стратегий компании Ж . Модели бизнес-процессов Модель ключевых показателей деятельности Процессная модель компании Модель корпоративной информационной системы компании Модель СМК компании Сертификация СМК по стандарту 180 9001 Рис. 9.9. Концепция построения СМК Подведем итоги 125 ,1 С <•>"- < у 1 *'« к ь„ ( г?5Е"Н >Э ^ Ы *■•> Ч*^- * ' Я' I' VI -г» * т»1Г'гчка • ^ш,ытд.»'\> 5 «.ОКОВ 3 Г -ГТЫГ'О') > * ^'Мк п И Приложение АЛ -чРЧЪ. 1 У«.Ч иА^’Ь Инструментальная среда ■>' эч*»>за^ > аш з х/ а »«§■ «?* 8 *\»@г№© -- ' ’ ч. ?/* ** Г 4 „1 .Л Человек, единст венным инструментом которого являет ся молоток, во всем видит только гвозди. лЧ' Вильям Маслоу Ниже даны примеры практического использования инструментальной среды АШ8 при бизнес-моделировании деятельности реальных компаний. Это вовсе не попытка продвижения данного продукта. Я вляясь поклонником этого инструмента и постоянно используя его в своей практической деятельно сти консультанта, я просто привож у примеры в той среде, в которой постоянно работаю. Знания о бизнес-процессах компании, документируемые п ри пом ощ и А Ш З Тооке!, не просто визуализируются в графическом виде, но и хранятся в элек тронной базе дан ны х. Таким образом обеспечивается непротиворечивость и многократное использование данных и моделей бизнес-процессов. Кроме того, к объектам моделей мож но присоединять другие объекты , создавая ссы лочную базу (см. рис. 7.2). Вся необходимая для дальнейшего создания СМК документация формирует ся в АШ8 как отчет, т.е. описания процессов для руководства по качеству созда ются непосредственно из моделей цепочек добавленной стоим ости, разработан ных в АШ8 Тоо1зе1;. Методологические и рабочие инструкции создаю тся на базе еЕРС-моделей. Самым удобным для проекта разработки КИСУ является описание БП ком пании в формате расширенной событийно-ориентированной модели — еЕРС (ехйепйес! ЕуепЪ-сЫуеп Ргосевз СЬаш) ([2]). Последовательность функций в рам ках процесса отображ ается в виде модели процесса, где для каж дой функции определены начальные и конечные собы тия. С помощ ью собы тия описывается сущ ествую щ ее состояние информационного объекта, которое позволяет осу щ ествлять контроль или влиять на технологию протекания бизнес-процесса. Таким образом А Ш 8 позволяет автоматически создавать руководство по ка честву, а такж е методологические и рабочие инструкции, используя различные типы моделей из своего репозитария. А.1. Моделирование в среде АК15 А.1.1. Выбор типов моделей АК18 для выполнения БМд При моделировании БП, которые будут положены в основу требований к про ектам внедрения отдельных модулей КИСУ (при подготовке ТЗ на каж ды й от дельный проект внедрения модуля — ИСУ), на этапе “ Как есть” рекомендуется использовать предлагаемую “ М атрицу необходимости применимости моделей А Ш 8 ”, представленную в табл. А.1. Примечания к табл. А.1. 1. Указанные модели необходимо использовать при проектировании моду лей КИСУ в качестве основных. 2. В случае необходимости возмож но использование других моделей (фор матов) в качестве дополнительных моделей по согласованию с заинтере сованными представителями заказчика и с исполнителями проекта моде-V лирования. 1 А.1.2. Примеры диаграмм и моделей На рисунках А .1, А .2 , А .З и А .4 в качестве примера показаны диаграммы не которы х моделей А Ш 8 . г <’ Г К С>1 ' 1 128 * . I >_ к ' * г ~/ % Приложение А №№ С о дер ж ани е БМ Н а зва н и е БМ Ф о р м а т А Р 15 1 Модель представляет собой последовательность событий и функций, отражающих логику выполнения взаимосвязанных действий, направленных на достижение заданного результата (заключения сделки, оформления сделки и проч ), процесса или отдельной его процедуры Модель процесса Модель процедуры еЕРС (ех1епс!ес) Еуеп1 Рпуеп Ргосезз СНат) еЕРС (та1епа111о\м) еЕРС (Ко\у б1зр1ау) еЕРС (Со1итп Й1зр1ау) 2 Диаграммы структуры Модели служат для отражения информационных структуры потока данных в потоков описываемых процессах. На модели отражаются так же и каналы коммуникаций между подразделениями в процессе получения и передачи документов или данных. В рамках данной модели все объекты могут быть детализированы на тех же моделях для более подробного описания 3 В состав модели входят информационные системы, которые выделяются по функциональному признаку (программные комплексы, базы данных, приложения и т.п ), и являются необходимыми для функционирования описываемых для данного модуля процессов V 1Р0 (1п(огта<юп Р1о\л/ с||адгат) АЗР (Арр1|са1юп Классификация информационных 5уз1ет О тдгат) систем Диаграмма прикладных (информационных) систем “ ■* ' — —— - ^ Н ео б хо д и м о сть для и н а м одуль К И С У пео оходипо сть для с о зд а н и я БМ с к в о з н о г о БП Модель сценария процесса (процедуры) является обязательной и предназначена для описания алгоритма выполнения отдельного сценария или процесса (процедуры), управляемого модулем КИСУ Модель процесса является обязательной Модель процедуры является обязательной Модель является обязательной и применяется для описания информационных потоков (с1а(а Ио«/) в рамках функционирования модуля КИСУ Модель является обязательной Модель является обязательной и применяется для описания прикладных информационных систем, используемых для построения модуля КИСУ Модель является опциональной «.гг й; Окончание табл. А 1 ЛЫЬ Содержание БМ Название БМ ''Ж- "У|?" ' Формат АК15 Необходимость для ТЗ на модуль КИСУ Необходимость для создания БМ сквозного БП Модель окружения функций используется для детализации функции, чтобы разгрузить модель процедуры и более детально описать бизнес-роли исполнителей функций, входящие/исходящие документы функции, информационные системы и другие ресурсы Ресурсное окружение функции РАО (РипсЪоп АНосаНоп Модель является Р|адгат) опциональной. В случае ее использования на модели процедуры ресурсное окружение функции не показывается Модель является опциональной На модели отражается структура знаний : группы документов и входящие в них документы. В рамках данной модели все объекты могут быть детализированы на модель классификации документов для более подробного описания. Диаграммы структуры знаний и документов Модель классификации документов К50 (Кпож1ес1де 5{гис1иге Й1адгат) Модель является опциональной Модель является опциональной и применяется для описания всех знаний (документы, технологии, регламенты), необходимых для функционирования модуля КИСУ 1.1 Процесс . Руководство 1 ..I ДейетвщЧ Процесса Структурное подразделение Структурное подразделение Рис. А.1. Диаграмма некоторого обобщенного процесса в варианте формата еЕРI С — Кот сНзр1ау План- график выполнения цроера-^^! Гттан-г рафя1Г выполнения проекта Рис. А.2. Диаграмма процедуры “Проведение рабочего совещания по проекту” 132 Приложение ^ Диаграмма потока данных при мониторинге показателей проектной деятельности Рис.А.З. Пример модели информационных потоков при мониторинге показателей БП Рис. АЛ. Пример структуры информационных систем компании А.1.З. Рекомендуемый перечень используемых типов объектов Перечень рекомендуемых типов объектов для различных типов диаграмм АК18 представлен в табл. А .2 -А .9 . VII ТаблицаА.2. Диаграмма целей Тип и символ объекта Описание Правило именования 0Ь)ес(1Уе Цель Имя задается в соответствии со смысловым содержанием цели. Примеры: Повышение прибыльности бизнеса; Сокращение издержек ■ >-М1-ЧУ" Рипс1юп •V ф Направление деятельности либо БП Ж >??»»<* * П ч. Имя задается в соответствии с наполнением рассматриваемого "г.ч г ».-> н процесса. .-*■ Примеры: * "“ ' " Продажи; ’* Выполнение проектов ' ~ СпИса! РасЮг Критический фактор успеха — условие, без выполнения которого невозможно достижение цели Имя задается в соответствии с определением фактора. Примеры: Привлечение внешних инвесторов; Развитие инфраструктуры Сп{|са1 Рас1ог Ключевой показатель деяте льности — количественный или качественный показатель, характеризующий степень достижения цели, или выполнения функции Имя задается в соответствии с определением показателя. Примеры. Для цели “ Увеличение доли рынка” ключевые показатели: доля рынка, принадлежащая компании; изменение доли рынка, принадлежащей компании Л Таблица А.З. Организационная структура Тип и символ объекта Описание Правило именования 0 гдат 2а1юпа 1 иш( Департамент Имя задается в соответствии с принятым наименованием департамента. Примеры: Департамент корпоративных информационных систем; Отдел маркетинга 0 гдап12а(юпа 1 иш( Подразделение, входящее в состав департамента Имя задается в соответствии с принятым наименованием подразделения. Примеры: Отдел интеграции программных средств департамента системной интеграции Огдагнайопа! ип! Инструментальная среда А Р 1 5 135 Окончание табл. А.З Тип и символ объекта Описание Правило именования Ро51<ЮП Должность Имя задается в соответствии с названием штатной единицы. Примеры: Директор департамента; Руководитель группы Розйюп Л» к в * - 1п1егпа1 Регзоп ФИО сотрудника 1п(егпа1 регзоп Имя задается в соответствии с ФИО конкретного сотрудника. Пример: * Иванов Иван Васильевич Таблица А.4. Дерево продуктов/услуг Тип и символ объекта Описание Правило именования Ргойис(/5еплсе Продукт/услуга Имя задается в соответствии с принятым в компании наименованием продукта или услуги. Примеры: Внедрение информационных систем Разработка заказного программного обеспечения для Интернет З е тсе Услуга Имя задается в соответствии с принятым компании наименованием услуги. Примеры: Проведение обследования БП предприятия 1п(огта1юп З е т с е Информационная услуга Имя задается в соответствии с принятым в компании наименованием услуги. Пример'. УУЕВ-сайт Шпйз1т аЛгап гегчсе 1 Таблица А.5. Матрица классификации процессов Тип и символ объекта Описание Правило именования Зсепапо Направление деятельности Имя задается в соответствии со смыслом рассматриваемого направления деятельности. Примеры. Продажи; Предоставление услуг Уровень группировки бизнес-процессов Имя задается в соответствии с принятым уровнем группировки бизнес-процессов и может принимать одно из следующих значении: Направления деятельности; Группы бизнес-процессов; Бизнес-п роцессы ......... А Маш Ргосезз нэп ргосаи .......... А 136 • *, '■ т Приложение А Окончание табл. А. 5 Типи символ объекта Описание Правило именования Ргасе55 Бизнес-процесс Имя задается в соответствии с наполнением рассматриваемого бизнес-процесса. Пример: Продажи услуг Г Л Таблица А .6. Д и а гр а м м а п р о ц е с с а Тип и символ объекта Описание Правило именования Рипс1юп Бизнес-функция Имя задается в соответствии с наполнением рассматриваемой функции и начинается с отглагольного существительного. Примеры. Проведение совещания; Выполнение проекта * Еуеп( Событие, отражающее исход выполнения одной бизнес-функции и необходимость инициации другой бизнес-функции Имя соответствует сути события, Примеры. Получен запрос клиента; Документ утвержден Орега(ог Операторы: “ И", “ ИЛИ”, “ ИСКЛЮЧАЮЩЕЕ ИЛИ” . Предназначены для логического связывания функций и событий Не имеют © © 0гдашга(юпа1 ишЧ •г >• Подразделение компании Имя задается в соответствии с принятым наименованием подразделения. Примеры: Департамент корпоративных информационных систем; Отдел маркетинга Должность Имя задается в соответствии с названием штатной единицы. Примеры: Директор департамента; Начальник отдела Инструментальная среда АР15 № ОгдашаЬопа! ип< Р051(ЮП РозШоп Окончание табл А 6 Тип и символ объекта Описание Правило именования Ргосезз ш1ег?асе Интерфейс процесса — бизнесфункция, связывающая подпроцессы в рамках одного БП Имя задается по правилам, определенным для бизнес-функции. Оосишеп! Документ Имя задается в соответствии с фактическим названием документа. Примеры Платежное поручение, Заявка; Договор Арр1|са(юп зу5(ет Прикладная система Имя задается в соответствии с фактическим названием прикладной системы Примеры М5 Рго)ес1; М3 ОиИоок, М5 (Ж|се С1аз(ег Кластер данных — информация, хранимая в базе данных прикладной системы Имя задается в соответствии с фактическим названием в прикладной системе либо исходя из смысловой характеристики данных. Примеры. Данные заказа, Данные об оплате ТесИтса! 1егт Технический термин — бизнеспонятие, используемое для определения специфичных технико-экономических терминов предметной области, используемых в компании Имя задается в соответствии с фактическим названием термина или понятия, принятым в компании. Пример Показатель качества работы подразделения Ргасег? (пЬлЬсе ТесЬгисэ! 1епп Т а б л и ц а А .7. Д е р е в о ф у н к ц и й Тип и символ объекта Рипс(юп /"" 138 > Описание Правило именования Бизнес-функция Имя задается в соответствии с наполнением рассматриваемой функции. Пример Регистрация заявки Приложение А ТаблицаА.8. Информационное окружение, трудовые и прочие ресурсы Тили символ объекта Рипс(юп Описание Бизнес-функция 0гдашга(юпа1 иш1 Правило именования Имя задается в соответствии с наполнением рассматриваемой функции. Пример-. Проведение рабочего совещания по проекту Подразделение компании Имя задается в соответствии с принятым наименованием подразделения. Примеры. Департамент корпоративных информационных систем; Отдел маркетинга Должность Имя задается в соответствии с названием штатной единицы. Примеры. Директор департамента; Консультант ______ _ » Ооситеп! Документ Имя задается в соответствии с фактическим названием документа. Примеры. Отчет; Договор Арр1]са(юп зуз1ет Прикладная система Имя задается в соответствии с фактическим названием прикладной системы. Примеры. Электронная база данных (301_ сервер); Электронная почта (М'сгоаоН ОиИооК) & йдгеайопа! ипй Р031(ЮП Р0311ЮП 1 | СИ*'*» 1п(огта(юп з е т с е Информационный сервис Вогтайоп зегук; ОрегаШд гезоигсе Операционный ресурс ■« Инструментальная среда АВ15 Имя задается в соответствии с фактическим названием сервиса или ресурса. Примеры. Проектный МеЬ-сервер; Интранет-сервер Имя задается в соответствии с фактическим названием ресурса. Пример: ЛВС центрального офиса компании - Окончание табл. А 8 Тип и символ объекта Описание Правило именования 0оситеп(ес1 кпо\л/1ес1де Документированные знания правила, регламенты и другие нормативные документы компании Имя задается в соответствии с фактическим названием документа, содержащего знания, регламенты и т.п. ОоЛитегйед кпош С1аз(ег Примеры. Регламент заключения контракта; Гост 34 601-90 “Автоматизированные системы. Стадии создания” ; Инструкция по заказу транспорта Имя задается в соответствии с фактическим названием в прикладной системе либо исходя из смысловой характеристики данных. Кластер данных — информация, хранимая в базе данных прикладной системы Примеры. Данные договоров, Метрики проектов; Данные об оплате Т а б л и ц а А . 9. Т е х н и ч е с к и е р е с у р с ы . Тип и символ объекта Описание Правило именования Орега1тд гезоигсе Операционный ресурс Имя задается в соответствии с фактическим названием ресурса, принятым в компании. Пример ЛВС центрального офиса компании <1 1_оса1юп Расположение Имя задается в соответствии с принятым наименованием места физического расположения ресурса. Пример : Ново-Рязанская 31/7 0 гдап12а1 юпа1 иш1 Подразделение Имя задается в соответствии с принятым наименованием подразделения. Примеры. Департамент корпоративных информационных систем, Отдел маркетинга -Ь ' 11 1 Огдап га юпа ипй Роз 1 1 юп Ро ®11юп Должность Имя задается в соответствии с названием штатной единицы. Примеры: Директор департамента; Руководитель проекта; Консультант т Ш А Приложение А Заполнение дополнительных атрибутов объектов организационной структуры подразделений С тем чтобы обеспечить автоматическую генерацию положений о подраз делениях компании и долж ностны х инструкций (в виде соответствую щ их от четов), для двух типов объектов организационной структуры подразделений (Подразделение и Должность) в моделях БП необходимо соблюдать правила за полнения, приведенные в табл. А.10 и А.11 соответственно. Таблица А.10. Правила заполнения для объекта Подразделение (Огдашга1юпа1 ипК) Свойство объекта Атрибут объекта Правило заполнения Наименование подразделения N8016 Имя задается в соответствии с принятым в компании. Примеры. Департамент корпоративных информационных систем; Отдел маркетинга 1с1еп1К|ег Задается в соответствии с принятым в компании сокращением. Примеры. Д КИС ОМ Код 0гдап'|2а1юп 1)п'|1 Соде Определяется финансовым отделом Статус ОгдашгаНоп 11ш( 5(а(из Для самостоятельного структурного подразделения — 0 , для несамостоятельного структурного подразделения — □ Аббревиатура ^ ^ ► ч *$ д Назначение подразделения Ргее А11пЬи1е5/11зег А11пЬи(е$ Тех1 1 Текстовая формулировка назначения подразделения Область деятельности Ргее АипЬи1е5/115ег АПпЬи1ез Тех* 2 Краткая характеристика области деятельности Задачи подразделения Ргее А»г|Ьи»е5/1)зег АНпЬиСез Тех1 3 — Ргее АНпЬи1е5/11$ег АПпЬи{ез Т ех(10 Формулировки основных задач, в которых должно быть определено назначение структурного подразделения Дата вступления в силу йа»а о? 1Ье 3(а(етеп4 Выбирается в календаре -.г Л Инструментальная среда А В 1 5 х4 < €! Таблица А.11. Правила заполнения для объекта Должность (РозКюп) Свойство объекта Атрибут объекта Правило заполнения Наименование должности № те Имя задается в соответствии с принятым в компании и включает в себя аббревиатуру подразделения. Примеры. Директор ЦУП Начальник отдела маркетинга ль »<■ т к г Категориям соответствуют следующие значения: Мападег — руководитель ЗреааПз! — специалист Етр1оуее — служащий Категория должности Са1едогу о? РозИюп Образование Ргее АипЬи 1е з / 115ег АНг!Ьи1ез Тех! 1 Квалификационные требования к уровню образования, необходимому для занятия данной должности Опыт, навыки, знания, подготовка Ргее АипЬи1ез/1)5ег АМпЬи^ез Тех! 2 Квалификационные требования к компетенции, необходимой для занятия данной должности Задачи Ргее АипЬи{ез/изег А1ЫЬи(ез Тех15 — Ргее А11пЬи1ез/1)зег АИпЬи4ез Тех» 10 Формулировки основных задач, в которых должно быть определено назначение должности Должностные обязанностиРгее АМпЬигез/Чвег А«пЬи1ез Формулировки основных должностных Тех1 11 — обязанностей для описываемой * Ргее АИпЬсЛез/изег АипЬи1ез должности Тех! 25 Права •к"» 1 >Я),?' ЭЧ€|«1 ' Ргее АПпЬи(ез/изег АПпЬи{ез Тех1 26 — Ргее А(1пЬи{ез/1)зег А«пЬи1ез Тех1 30 ' 40© • ' Ответственность Ргее АНп'Ьи1е5/115ег А({пЬи*ез Тех( 31 — Ргее АипЬШ ез/ивег А{1пЬи(ез Тех{ 35 Дата вступления в силу Ра1а о( 81а1етеп 1 Права, характеризующие специфику данной должности (для руководителей секторов и других внутрипроизводственных подразделений — права по организации работы в подразделении) Виды ответственности, характеризующие специфику данной должности (для руководителей секторов и других внутрипроизводственных подразделений — ответственность за организацию работы в подразделении) Выбирается в календаре Использование типов связей объектов моделей Типы связей всех объектов моделей необходимо использовать строго в соот ветствии с методологией инструментальной среды ([2]). 142 Приложение А I А.2. Практическое руководство по созданию моделей в АГС18 При выборе пакета А Ш 8 как среды моделирования и ее самостоятельном освоении пользователи сталкиваю тся с отсутствием именно практического ру• ководства (инструкций) по работе с этим ПО. Я попытался восполнить этот зияющий пробел для тех, кто пользуется “любез нопредоставленными копиями” клиентской части А Ш 8 Тоо1зе1; для ознакомления свозможностями и функциональностью его многочисленных нотаций, но не имеет возможности пройти дорогостоящий курс обучения у дилера этого продукта. А.2.1. Начальная настройка АР15 Для создания базы моделей (репозитария) создается новая база данных про екта. Для ее создания необходимо запустить приложение и выделить в его окне локальный сервер 1_ОСА1_, а затем щелкнуть на нем правой кнопкой мы ш и и вы брать в раскрывшемся контекстном меню команду 0а1аЬазе (как показано нарис. А. 5). ,л| рйе Еск Угвю ЕуаЬ^е □ У М «■ Ш Г Ж ~ • I | Мос^е)& О Ь № | Зк АЯ15 №Сшогк ! -1 8 Ш *" я 2 йреп а «к Енр1оге ш “ Ш ЙЛ. Яепате л 1 1 и п. гиппак5 Л]1апдиаде$ ^ Т азкз 3^1тргоуетегА5 _}БП ФСК 1 ОксоппесЬ ■ т Я I>аЬэЬа 1 1 | ЦакэЬазе | Рис.А.5. Создание вАВ18 новой базы данных Исходно база данных создается только на латинице — переход на русский язык можно осущ ествить только после ее создания, путем добавления русского в список возмож ны х языков. Для этого следует раскрыть компонент ВР РЗК и выбрать папку 1_апдиадез, а затем щ елкнуть на ней правой кнопкой мы ш и и вы брать в раскрывшемся контекстном меню команду М е м ^ а п д и а д е , как показа но на рис. А .б. Внимание! После каждого изменения настроек систему АК18 необходимо перезапускать, чтобы эти настройки вступили в силу! Инструментальная среда АР15 143 т с». & Мос1е15 ЦАККМекиюгк Й «-0СА1 + ^ ( эпди^дез Мате |^Епд15Ь (ЫпЛес! |ч[рРгвпсЬ (Ргапсе) ]ч!Рсегтап (Сегт |ч§?1ЬаЬап (Ка1у) | ® ^рапе$е »< Ш У$ег5 а Ропк РогтаЬз Й Ш И Г" й Та5к> 1трго __На? — { СогЛдцга&оп + ? вр - ^ 3 ВР РБК 0Рег> Еко1оге а О бпфс _ _ ■В «К СНГ Н к + Ц Эето62 |^'Р.и55ап ■■ЭМратзЬ (ТгасЙ! 1апдиаде 1апдиаде 1_апдиаде Ьапдиаде 1_апдиаде 1апдиаде 1апдиаде 1апдиаде 01 Рис А .6 Добавление русского языка Далее в новой БД создается папка Р е п о зи та р и й , имеющая, например, такую вложенную структуру папок моделей, которая показана на рис. А .7. ( у ВР Р5К Л Ц5«Г5 а Рогй РогтаЬ5 ш Ьапдиадег 28 Тазкз а I 1тргоуетеп15 - ,_3 БП ФСК БП А5 15 + _ ! БПВУ + Структура бгоир бгоир Сгоир бгоир Сгоир Сгоир Сгоир Сгоир Сгоир Сгоир Сгоир Сгоир Сгоир Сгоир Сгоир О. о о (5 1Я »1 ИШЬ I Управление ИТ IИнвестиционн I Оперативное „]ПХО . 1Стратегическ ^Технический н _ 1 Управлениез __1Управлениеп _1Управление с __! Управление ф _! ^кономическо + _______1 Взаимодеиствие с инвесторами луатация + и_1 Делопроизводство вление РК (Ь Инвестициоммое планирование [+ ______ 1 Оперативное управление пдеиств ■Р _______] Предоставление услуг произвол 1+ ______ ____________1 Проектирование ктирование Й ПХО _1Юридическое Ь (_) Стратегическое планирование 1Предоставлен Коррект планов развития л Регл взаим с субъектами ОРЗ Ж Страт план ЕЭНС Л ь Стратегическое планирование М (ЦЗ Техническим надзор ЕЙ ^ Управление РР 1? Л ] Управление закупками +1 ,__] Управление ИТ *+] Л ] Управление персоналом + ] Управление собчтвенностью + | Управление финансами + _ | Экономическое П и Б + _1 Эксплуатация и ремонт + Юридическое обеспечение + _I БП ТО ВЕ___________________________ ; Сгоир Сгоир Рис А.7. Структура папок репозитария моделей Модели находятся в папках соответствую щ их функциональных областей (Ф О ). Все модели пока имеют статус АЗ-18. Указанные папки являю тся только рекомендуемыми и могут иметь внутри себя сколь угодно слож ную вложенную структуру, определяемую разработчиками. 144 ‘« А ь ц - г . г Приложение А I* 4Начальные настройки рабочей среды АК15 ' « . Подключение к базе АК18 осущ ествляется двумя способами: 1 • по умолчанию; ■ • с помощью команды меню 1_од 1П. В Параметры настройки подключения к базе по умолчанию устанавливаются на вкладке Ьод 1п диалогового окна ОрИопз, раскрываемой выбором команды 1 меню\/1е\л/,=>Ор1юп| =>1-од 1п (рис. А .8). На этой вкладке необходимо задать значе ниядля следующ их параметров: I • 11зег йе^аиИ — установить флажок; • 11зег Ы а т е — значение 5уз1ет; • Раззжогс! — выбранный пароль; • 0а1аЬазе Ьапдиаде — значение Кизз1ап; • РН1ег — значение Еазу ПИег. I После выполнения данной настройки вход в базу АК18 будет осущ ествляться Г по умолчанию. ВГ1 "п ' " АКпЬиЛез СотропегА® Соп&дигаЬюп ОеРаиИ: Ргосейигез Еуа1иаЬюп5 Ехр1огег + бепега! СгарЫс ЕхрогЬ 1_ауои1: Ргосе^иге '' : ~ 1 5$ Як ✓ 11$ег Ое(аиЙ$ Шег Мате Ра$<здосс1 0а(аЬазе 1апдиаае |р1и58ап ВЕЁВЗ + Мегде Мос1е1 Сепега&оп - Мос!е1 ОрЬюп5 ((ЗоЬа!) СоппвсЬоп Арреагаг< Мос!е1 Арреагапсе РПГЛОрЙОПЗ БетапЬс СЬеск Тоо11гЛедгаЬоп ХМ1. Ехрогк + ХМ1. Ттрогк РгЙег 0е(аи!Ь р|Иег \ - ^^гтт^аКэг 0<°(аиЙз Разнога ог 0 а^Ьа-^е Айтт!$(га1ог Соп(|диа1юп Аёггат&аксг и_^___________ ___ ,______________________________________________ Рис.А.8. Настройка подключения к базеАК18 Работа с системой АК13 на русском языке Для заполнения атрибутов на русском языке необходимо не только разре шить присутствие в базе А Ш 8 русского языка, но и присвоить русскому языку шрифт, содержащий полный набор символов кириллицы. В качестве шрифта по умолчанию можно рекомендовать выбрать шрифт Аг1а1 N8 г г о л у размером 10. Настройка шрифтов осущ ествляется следующим образом. В дереве папок базы Инструментальная среда АР15 145 данных выберите папку Роп1 Рогта1 и щелкните на ней правой кнопкой мыши, после чего выберите в раскрывшемся контекстном меню команду Ме^ОРоп! Рогта4, как показано на рис. А .9. 15- [АЯ15Енр1огег - {.апдиадек] ♦ ЛК а! Рйе Е«Й Ую# ЕуаЪаЬе Нф 1 о 6$ -* ?. 1В & 1апдиаде5 \ ---‘'1 Щ Щ Сопр|дигаСюп я «» вр |& г „ ^ |@РгепсЬ (Ргапсе) ] @ Сегтап (Сегт |§ 1 Ы |а п (1Са1у) |®3арапе5е 1 9 Яи5$1ап §5раш5Ь (Тгаск! Я ^)ВРР5К ® Ц56Г5 й ВГ Й ] Ьапд Ореп ЗУ Та51< Ехр оге 1 ■ГФ.1 1трг>| Ч С ] БП ф ! (.апдиаде [.апдиаде 1апдиаде Сапдиаде (.апдиаде 1апдиаде I.апдиаде И Ш СМ $ Чв С>ето62Рис.А.9. Выбор требуемого шрифта П о м и м о этого необходимо разрешить возмож ность отображ ения атрибутов диаграмм на русском языке. Для этого следует раскрыть вкладку АКпЬи1ез диа логового окна ОрИоп, выбрав команду меню \/|е№1=>Ор110п,=>АипЬи1ез, а затем установить флажок для русского язы ка (рис. А.10). цщря Апа^з/Аттавогг АКгчЫ &е* Сотропеп1:5 СопЬдцгяйоп + „+ + +г ОеРаиИ Ргосейигез Еуа1иа1:юп5 Ехр1огег Сепега! «ЗгарЬс Ехрог1 1ауои1: Ргосес1иге 1.од 1п Мегде Мойе! СепегаЬюп Мос1е1 ОрЬопз (01оЬа1) 5етапЬс СЬеск Тоо11пкедгаЬюп ХМ. Ехрогк ХМ11трог1: АКчауз сЬр1ау аИэтЬи»ез ю (Не М1омпд 1апдиаде$ Ма)ау (Ма1ау$1а) Могшедюп (Вокгла!) Мог^ед 1ап (Мупог$к) | Рог1идие$е (Вгаг||) Рог*идие$е (Рог^ида!) Н и$51ап ЗегЫап (СупИю) ЗратзИ (Агдеп1та) 5рап1$Ь (Во1ма) 5оат$Н (СЫе1 Рис. А.10. Задание русского языка для отображения атрибутов Настройка сетки экрана моделирования , Для облегчения позиционирования объектов в моделях рекомендуется разре ш ить использование сетки. Для этого на вкладке диалогового окна ОрИоп, рас крываемой выбором команды меню \/1е\л/с>Ор1юпс>Мос1е1 ОрИоп(С1оЬа1)| =>Мос1е1 146 «V ч о Приложение А Арреагапсе, следует установить флажок опции II зе Спс1 и задать желаемый шаг сетки с помощ ью ползунка Опс1 \Л/|сКН (рекомендуемое значение — 2), как пока занона рис. А .11. Апз1 АйпЬиЬез Сотропепкз Соп&дигаЬоп ОеРаиИ Ргосес1иге5 Еуа1иа1юп5 Ехр1огег Сепега! <згар1ис Ехрогк 1_ауои1: РгосеЛге 1_од 1п Мегде Мос1е1 Сепегайоп Мос1е1 ОрЬога (С1оЬа1) Соппес&оп Арре<згап( Моде! Арреагапсе РппЬ ОрЬюпз 5етапйс СЬеск Тоо! 1гЛедгаЬоп ХМ1. Ехрог1 ХМЬ 1трог( 1к. ?? и«е ^/аИрарег Тех* АииЫез ш ЗутЬо! Тегпр1а(е Н|с1еА -ядпг еп1 1си й<6 *Л Л V 1)$е бгкЗ еы •/л! Рис.А.11. Включение сетки ПГйг ЭН </ V Наследование прав доступа к папкам АК15 Для обеспечения наследования прав доступа, определенных для папки, при создании в ней новой подпапки необходимо на вкладке Ехр1огег диалогового окна Ор1юп (команда меню У ю д аО О р^оп^Е хр^гег) установить флажок опции Сгеа1е Ые\л/ Сгоирз \л/|1Н 1пИеп1апсе оТ Ассезз РпуПедез (рис. А .12). Рекомендуется установить данный флажок на всех клиентских м аш инах, на которы х будет ис пользоваться А К 18. Апа1у5^Д а АКпЬикез Согпропеп($ СопйдигаЬоп ОеРаиИ Ргосес1иге5 Еуа1иа1юп$ а) Сепега! (агарЬс ЕхрогЬ 1ауоиЬ Ргосес1иге 1од 1п ^ Мегде Мойе! СепегаЬоп - Мос1е1 ОрЬопз (С1оЬа1) Соппейюп Арреагапс Мос1е1 Арреагапсе РппЬ ОрЬоте 5етапЬс СЬеск Тоо11пЬедгаЬоп ХМ1 Ехрог* Ш ХМИтроЛ Б *» и^'1 'У В|зр1ау Сотр1е(е Сго <р Ра*Ь * I геа(е Ы*ч\ л сир ^ч1ЫпЬег1япсе о( Аи-сезз Рп\Педе$ О $р1ау ,0 в и 0 0 Роп1 Ьгта( тападетепк 1тргоуетеп1$ 1_апдиаде тападетеп( Та$к$ ^ ег тападетеп! 51аг!: Ыоир и ге 5 ^ Ь оир Рис. А.12. Разрешение наследования свойств папки создаваемыми в ней подпапками Инструментальная среда АР15 1Й7 Настройка привилегий на рабочих местах разработчиков Для правильного определения привилегий на группы и модели, создаваемые отдельными разработчиками, необходимо выполнить соответствую щ ую на стройку клиента АК18 на каждом рабочем месте. Для этого следует открыть ди алоговое окно Орйоп на вкладке Ехр1огег (команда меню \Ле\л/с>С)р1юпс=>Ехр1огег) и установить на ней флажок опции Сгеа1е Ые\л/ Сгоир \лл1(п 1пЬеп1:апсе оТ Ассез$ Ргм1едез (см. рис. А .12). Если данная настройка не будет выполнена, то созданные в новой группе модели будут видны только том у разработчику, который их создал, а права до ступа других пользователей к этим моделям смож ет определить только админи стратор репозитария. А.2.2. Общие положения по моделированию Для некоторых видов деятельности более характерна функциональная мо дель: для функциональной области (ФО) строится дерево функций (БТ) и функ ция разбивается на процессы (еЕРС), ее реализующие. Но для некоторых видов деятельности более характерна процессная модель: для ФО строится сценарий процессов (УАБ), которые затем детализируются в формате еЕРС. Там, где это целесообразно, вариант представления ФО в виде ‘Т Т — еЕРС” выбирается разработчиком модели исходя из конкретного вида деятельности. В любом случае все бизнес-процессы, реализующие некоторую функциональную область, в итоге должны быть описаны в терминах еЕРС. На рис. А .13 показаны уровни моделирования процессов, соответствующие им типы моделей и и х взаимосвязи ([1]). Общими для всех создаваемых моделей являю тся следующие правила, трс бования и замечания. • Для обеспечения п ростоты восприятия и высокого уровня наглядности моделей детального уровня желательно, чтобы каж дая из них: . содержала ограниченное количество (не более 10-15) функциональны* объектов; . умещ алась на листе формата А 4 (в качестве исключения — АЗ). • Необходим специальный значок, размещаемый ниже и справа от объек та, который будет указывать на то, что данный объект (организационная единица либо бизнес-функция) детализирован на отдельной модели. 148 и* Приложение А Модели процессов верхнего уровня Формат модели-VАО Л {___ Модели сценария процесса V Формат модели - VА^ Функционал компании Формат модели» РТ Дерево функций подразделения Формат модели - РТ V .Ячй:.. Модели процессов Формат модели - еЕРС Модели процедур Формат модели - еЕРС т Модели технических терминов Функциии или процедуры Формат модели ТТ г Модели технических ресурсов Функции или процедуры Формат моделиТК ззг „"•'Т. , _ Модели окружения Функциии или процедуры Формат модели РАО Рис. А.13. Уровни моделирования процессов и взаимосвязь ис пользуемых моделей А.2.3. Наименование объектов Наименование объекта, графически отображ аемое на модели (поле Ы ате в свойствах объекта), не может, сост оят ь более чем из 80 символов, включая пробелы. В связи с этим ограничением для длинных названий объектов в поле Ыате необходимо применять сокращение, а полное название приводить в поле, доступном по команде ОезспрИоп^ОеЯпйюп. В поле № т е для перехода на новую строку следует одновременно нажать клавиши <С1г1+Еп*ег>. Инструментальная среда АК15 149 Разрешение конфликтов наименования объектов 1Н При задании имен вновь создаваемого объекта периодически мож ет появ-1 л яться предупреж дение о том, что объ ект такого типа и с тем ж е именем уже! сущ ествует, т.е. задаваемое имя не является уникальным в рам ках проекта. 1 В этом случае целесообразно п росм отреть весь список моделей, где этот объект! встречается, после чего либо использовать уж е имею щ ийся объект, либо дать! новому объ ек ту другое имя. П оэтом у в случае появления такого предупрежде-1 ния выполните следую щ ее. а • Установите, к каком у типу информационной системы относится данный 1 объект. 1 г • Если новый объект описывает уж е имеющ ийся объект (например, поле справочника или поле документа, использующ его информацию этого справочника), целесообразно использовать уж е сущ ествую щ ий объект. 1 1 • Если новый объект относится к другой информационной системе, целесо образно создать новый объект, несколько изменив его имя. • В случае, если данный объект физически имеет одно и то ж е значение, то необходимо использовать один и тот ж е объект. • В случае, если объекты имеют различные физические значения (напри мер, это поле ГО документа А и поле ГО документа В), то необходимо ис пользовать различные объекты. А.2.4. Создание моделей П риступая к созданию новой модели, в окне программы следует выделить папку, где будет находится эта модель, а затем щ елкнуть на ней правой кнопкой мы ш и и выбрать в раскрывшемся контекстном меню команду Ые\л/ОМос1е1, как показано на рис. А.14. Далее, в открывш емся окне мастера создания моделей следует выбрать тип создаваемой диаграммы. Например, для диаграммы процесса или процедуры необходимо выбрать тип еЕРС (рис. А .15). При заполнении рабочего поля модели объекты мож но просто копировать (как обы чно — щ елчком мыши) из панели объектов справа непосредственно в рабочую область. Далее для добавленного объекта необходимо заменить исхо дное название его типа (на английском языке) на русское название, которое ему долж но бы ть присвоено в данной диаграмме. ’ Приложение А I м теь. нднв* ,< Г • Н 'Ч ч ■ РУ ,Ь, '’"Ч. „ОС >'"* >11 4» КГ* ’ 1к5С‘ а ^ 'Ни \ *П ч\ »• ^ - _1 БП ФСК + _) примеры БПВУ - ^ ФО + Оперативное управление & 1 } Ореп ^ Екр1оге | ^ <“и1: Е Чй & ру а <Н смт н « • Випо62 5 ► ! 5 Регате " Г ' « СУ 6Г011Р 1 1~у ОЬ]ес(: Л Мос1е! ьцп ► Е/а1иа>-е Д551дп 1с1еп1-|р1еГ5 | 1пЬегЛ А^пЬи1еь ► Ртс1 1 ► 1 1 ЕхрогЕДгпрог!Ргорег&ез Рис.А.14. Создание новой модели г ; — ~ *1 г ^ иу м д не АРЛо Нои$е ап<Йке II} Ж щ "Л 1 1 ] М ЬйЫ V V* ^ V Огдагагайоп 0а1в Ргосеззез РиПС(ЮП$ Ргос!иг^/5е1У!се5 Мис1е1 Т О'чПгаг ?от13?1 п Е Ви$те$$ «сепапо Й1ад»ат еЕРС (со1итп Л$р1ау] ?|=ЕРС (Иопгоп1а1 *аЫе с1|$р1ау) *РР1 | ■ | N6x1 > | Сапсе! И | Нейр Рис.А.15. Выбор типа модели в окне мастера Инструментальная среда АР13 | 'VI' > 5 *, л 1€ 151 Выбор типов объектов проводится в соответствии с рекомендациями, приве денными в предыдущем разделе данного приложения. При организации связи меж ду объектами, в раскрывшемся окне 5е1ес1 Ре1а1юпзЫр Туре выбирается ее тип — в соответствии с содержанием действия или работы и функциональными обязанностями ее исполнителей (ехеси1ез, | ’з 1Т гезропз1Ые Тог, (Зесйез оп, и т.д.), как показано на рис. А.16. Бизнес- Процедура “ Закупки и выбор Поставщиков для ИТ-проектов" 0гдап(2а(юпа1ипй |>дитель |>екта I Потребитель результатов проекта РигиЛюп Определение потребности в обордоеаниии Зеуега! ге1й(юп*Н|р (./ре* аге ро'<лЬ\е ЬеГ^ееп {Ие !лю оЬ|ес(з Ч'ЬсЬ ге1аГ»0Г|$Н>р (уре «оик) /ои !(ке 1о иге? Ауа|1аЫ^ Соппес1:юп Туре* Коммерческие предложения ТП0Ис1В]ДМ^С^ В ыбор Пост основывается ^ (5 (есНпюаНм гегроплЫе Гог екеси1е$ 1$ II ге$роп5|Ые Гог с1ес1с1е8оп соп(пЬи1е$1о ти$( 1п?огт аЬоиГ ге$иИ оГ П Кл ГГ||=НдКп ► кеер $ате соппео(юп >уре Гог 1Не иоппес^оп 1! уои ‘лн^Н (.о гапсН (Ье зеШпа (ос кееретд {.Не соппес*юп 1уре юМе Е5С кеу ог (игп II*р сотес^ст тос!е оп о; о!Г рге$^ Чче УСЛОВИЙДО-г Рис. А.16. Выбор типа связи между объектами Для вставки необходимых комментариев следует выбрать команду меню 1пзег1^Ргее-Рогт Тех1 (рис. А.17). В раскрывшемся диалоговом окне Ргорегйез Ргее Рогпп Тех! следует установить в группе 0|зр1ау флажок опции Аз С оттеп1, а затем в списке Роп( Рогта1 выбрать требуемый формат шрифта (рис. А.18). Для связывания моделей друг с другом или детализации Б П или функций на других моделях необходимо выделить требуемую модель или объект, щел кнуть на нем правой кнопкой мы ш и и выбрать в раскрывшемся контекстном меню команду Азз1дптеп15,=>Сгеа1е или Ореп (рис. А.19) — в зависимости от того, будет использоваться уж е имеющ аяся модель или необходимо создать но вую (рис. А . 20). Для новой модели в раскрывшемся окне мастера потребуется выбрать ее тип. 152 Приложение А I В Д ^ Р)1е 'З Е Ш Еар Vе а (т й о п Е /а!иа(:е 1п5ег1: Ш Д капде Е ' ’>Л/1пс1о<а; Не1р о &I * д> Стратегическое планирование вмиаааввВВПИВВИВНПШВННМ 1 а!Ш П М М |! Мос1е1 АКпЬиЛе Энергетическая концепция России | Д стратП а н П рарам ш техлере*осружения ЕНЭС на 10 лет ^ Стратегочесв» планирование ЕНЭС ч Ежегодные корректировки планов р з з т т и я ЕНЭС Л Рис.А.17. Вставка комментариев / хСтратегичрское Ргее Р о г т Тс» Ргее Рогт Тех!: Р.ерге5егАаЬс Андптеп1 ЦеК <• Селегее! В|дН 0 )5р 1ау У А& СоттегА Сапсе! ННр Рис.А.18. Определение параметров комментария Инструментальная среда АР13 153 ..'п.'[-'■ ■ |,|Ц .И .'ГГ!? иимшш1 гар 1"""""' %м а& а № Ыош а а Не1р 0\Ш Стратегическое плаинр Ехр1оге 1 СиС Сору )- 0е!е1:е Энерге Яепате Акдп (:о бпй 5е(ей йетоуе 1пГоггпа1:юп Магкз В.ер1асе Р1асе апс! Соппеск А551дп§етш1:1С5 ■ АйпЬике* - Л*Кип Еу§1иаЬе 1пНеп1- АКпЬикез Сотраге ютраимв и»гелл>ства { ЕССЭ ^ _ '"■■дачч» ртаЛ I ® 1 Ргорегкгез Рис.А.19. Связывание моделей Модель в нотации еЕРС предназначена для описания алгоритма выполнения процедур в виде последовательности функций, управляемых событиями. В мо дели этого уровня главное внимание уделяется последовательности выполнения функций. Для описания условий в модели имею тся собы тия и правила, которые м огут описывать слож ные алгоритмы выполнения процедур. И ными словами, модель в нотации еЕРС представляет собой последователь ность собы тий и функций, отраж аю щ их логику выполнения взаимосвязанных действий, направленных на достиж ение заданного результата (заключения сделки, оформления сделки и проч.). Любая модель процедуры обязательно начинается и заканчивается одним или нескольки ми событиями, или интерфейсами в другие процедуры. Для представления интерфейсов используются специальные объекты Ргосезз 1п1егТасе (тип объекта Рипс1юп). Для удобства восприятия создаваемых моделей необходимо придерживаться ряда правил графического расположения объектов. 154 ьа »,*>’ Приложение А Г; 12? 13 ^ X Чэ С Ч| У Рис. А.20 Выбор типа новой модели , > В частности, общ епринятым соглашением при создании моделей в нотации еЕРС является расположение последовательных собы тий и функций в направ лении сверху вниз. Документы, бизнес-роли, информационные системы, продукты /услуги и тех нические ресурсы , как правило, располагаются относительно ф ункции следую щим образом. • Входящие документы — слева сверху друг под другом. • Исходящие документы — слева снизу друг под другом. • Статусы — слева от документа. „ / • Исполнители (бизнес-роли) — справа сверху. • Информационные системы, модули информационной системы — справа по центру. • П родукты /услуги и технические ресурсы — справа снизу. Однако при большом количестве функций и связей меж ду ними допускает ся расположение объектов в пределах видимости функции — для сохранения целостности восприятия хода процесса или процедуры. Инструментальная среда АР18 155 А.З. Рекомендуемый регламент описания БП в еЕРС-модели АР15 При создании моделей БП для реализации системного и процессного подходов в целях выполнения последующих проектов компании заказчика необходимо ру ководствоваться определенными требованиями в их описании. Набор таких тре бований содержится в международных стандартах серии 180 9001:2000 ([4]). В соответствии с этими требованиями, модель БП должна включать следую- , щ ую н еобходимую информацию. 1. В ходы /поставщ ики процесса (ргосезз нгЬег&се, (1оситепЬ, 1есЬшса1 4егш). . 2. В ы ходы /клиенты процесса (ргосезз тЪег^асе, с1оситеп1,16011111031 Ъегт). = 3. Ресурсы : персонал, оборудование, информация, среда (о гд а т га и о п ипй, . аррИса^юп зуз^ет). 4. Технология выполнения процесса (еуепЬ, {ипсЫоп, орега1,огз). I 5. Все этапы цикла управления (планирование, выполнение, контроль, ана- • лиз, принятие решений). 6. Контрольные точки для измерения показателей. 7. Возможные отклонения от нормального хода процесса. 8. Показатели процесса и данные удовлетворенности клиентов. 9. Участие руководителя (управление процессом). Рассмотрим примеры представления этих требований в нотациях еЕРС-моде ли. На рис. А .21 показано описание БП, представляющее собой последователь ность работ и собы тий. Эта базовая цепочка в каж дом последующем примере будет расш иряться — соответственно, ресурсами, циклом управления, показа телями, другими процессами, документами и регламентами. ‘-1 / ,, \ О пи са н ие БП представляет собой базовую цепочку работ { функций) и со бы ти й (т а к назы ва ем ую еЕ Р С - цепочку), преобразую щ ую входные д а н ны е п роцесса в его вы ходны е результаты Рис.А.21. Описание работ и событий процесса 156 — базовая еЕРС-цепочка .А . Приложение А •! •* ?*» Описание входов и выходов БП «ем» ы »л*чгг А®*и,_-*з»»й€! Пример базовой цепочки с описанием входа и выхода процесса показан на . 1г-т & я. г, рис. А . 22. г \ -У\ 1 Процесспоставщик №1 Ч_ Л П роц есспоста вщ и к № 2 П роц ессклие нт Рис. А.22. Описание входов и выходов процесса Описание ресурсного окружения ~ - ~ - Пример базовой цепочки с описанием ресурсного окруж ения показан на рис. А.23. Рис.А.23. Описание ресурсного окружения работ Инструментальная среда АВ13 157 * ,»* Описание технологий и участия руководителя Пример базовой цепочки с представлением технологий выполнения процесса и описанием участия руководителя показан на рис. А .24. Рис.А.24. Описание технологии и участия руководителя Описание цикла управления процессом Стандарт 180 9001 указывает на необходимость описания цикла управления процессом в соответствии с так называемым циклом Деминга-Ш ухарта ([4]) — “ Иап-Бо-СЬеск-АсМоп” (планирование-контроль-анализ-принятие решений). Пример базовой цепочки с описанием всего цикла управления процессом по казан на рис. А .25. Описание контрольных точек измерений и показателей процесса Стандарт 180 9001 указывает на необходимость разработки показателей до стиж ения результатов процесса и описания контрольны х точек в БП, где прово дится их мониторинг ([4]) — пример такого описания показан на рис. А.26. Описание отклонений от нормального хода процесса Рассмотренный выше цикл управления процессом должен предусматривать корректирующ ие действия при возникновении возмож ны х отклонений от нор мального хода процесса ([4]) — пример такого описания показан на рис. А.27. 158 < */* - «.зет- Приложение А Рис.А.25. Описание цикла управления процессом вы по лн ен и я р а б о т по п ро екту Рис.А.26. Описание контрольных точек измерений и показателей процесса Рис.А.27. Описание отклонений от нормального хода процесса Приложение Б Расшифровка аббревиатур АШ8 — инструментальное средство моделирования деятельности компании. ? ВР1 — уровень развития бизнес-процессов (В изтевз Ргосезз 1тргоуетеп4). 4> ! В8С — система сбалансированных показателей деятельности (ССП). СЮ — топ-менеджер по организации информационных систем (С1ие# Хп&гта^юп ОШсег). еЕРС — расширенная событийно-ориентированная модель (ехЪепйей ЕуегЛ-ёпуеп Ргосезз СЬат). ЕКР — система планирования ресурсов предприятия (Еп^егрпзе Кезоигсе Р1апшп§). ГТ — дерево функций (РипсЪюп Тгее). ; ГОЕР — семейство методик моделирования деятельности компании. г \'АБ — сценарий процессов. ? I АБМ — администратор бизнес-моделирования. БД — база данных. , , г ч ~» БМ — бизнес-модель. БМд — бизнес-моделирование. БМП — бизнес-модель подразделения. БП — бизнес-процесс. БФ — бизнес-функция. ЖЦ — жизненный цикл (производства). * ИБМ — интегрированная бизнес-модель. ИТ — информационные технологии. КИСУ — корпоративная информационная система управления компанией. » КК — “ качественная” компания. > *, КПД — ключевые показатели деятельности. КПК — качество потенциала компании. у , (^ МБП — моделирование бизнес-процессов. . „ , , МСМК — модульная структура СМК. ОМСК — оптимальная модель системы качества. ПО — программное обеспечение. ПЭ — показатели эффективности. СА — системный аналитик. СМК — система менеджмента качества. * „ ССП — система сбалансированных показателей деятельности (В8С). ТЗ — техническое задание. ФО — функциональная область. Литература [1] Каляное Г.Н . Теория и практика реорганизации бизнес-процессов, М.: “СИНТЕГ”, 2000. [2] “ Инструментарий АК18. Методы” . Файл формата РБР. Поставляется вместе с демо версией системы АК18 Тоо1зе1. [3] Ы :1 :р ://м м м .1 с 1 е ^ .с о т . Полное описание стандартов ГОЕГ. [4] 180 9001:2000. Система Менеджмента Качества. Требования. [5] М1сНае1 Наттег, г]ате8 СНатру. К е е п ^ т е е г т ^ ЪЬе СогрогаИоп: А Маш1ез1ю & г Ьизт е з з геуо1ийоп, 1993. [6] Слиньков Д. Бизнес-моделирование для внедрения ИСУ предприятия. Директор ИС, №3, 2001. [7] Холланд У., Скарк Г. Инвестиции в ИТ: А дальше — тишина?, 81га1её1с Ппапсе, Бесетйег 2001, Перевод статьи — СОЫЗТЛЛ’ШО.РШ, 2002. [8] Ы ;1:р: / /и м и . гп'Ь ег Е а с е . г и /са /Ъ р м з -П . Й ш . Полное описание ВР\У1п. [9] Ы:1;р: //м и м . л_п±ег Е а с е . г и . СА8Е-средства: в борьбе со сложностью мира. [10] Ы;1;р : / /м и м . хп Ь ег 1 :а с е . ги . Чеботарев В. Статья “ Моделирование бизнеса: сред ства и методы”. [11] 1тЫ:р : //м ю и .и т Ь е г ^ а с е .г и . Рубцов С. Статья “Сравнительный анализ и выбор средств инструментальной поддержки реинжиниринга бизнес-процессов”. [12] Ильин В. Руководство качеством проектов. Практический опыт, “Вершина”, 2006 . [13] Ы:1:р: //м и м .а 1 р 1 п а .г и /Ъ 0 0 к з /а и 1 :1 1 0 Г 5 /4 /, ]п-Ы:р : //и м и .а 1 р х п а .г и / Ь о о к 8 /а и ^ Ь о г з /1 1 4 /. Бережливое производство: как избавиться от потерь и до биться процветания вашей компании, “Альпина Бизнес Букс”, 2005. [14] Коплан Р. Сбалансированная система показателей. От стратегии к действию. “Олимп-Бизнес”, 2005. [15] Кобаяси И. 20 ключей к совершенствованию бизнеса. Практическая программа рево люционных преобразований на предприятиях. М.: РИА “Стандарты и качество”, 2006. |и указатель производственных процессов, 77 Бизнес-модель, 20; 35 адекватность, 69 анализ качества, 55 ^ архитектура, 42 документирование, 56 интегрированная, 21; 23 ' 8 компании, 105 ' критерии качества, 71 описание, 52 *° подразделения, 110 ■' построение, 27 ■* создание, 39 тестирование, 71 типовая, 125 уровни детализации, 43 Б изнес-процесс, 16; 20 ' документирование, 97 * методика моделирования, 65 методика описания, 59 моделирование, 32; 128 огр ан и ч ен и я ,77 описание, 30; 67; 128 оптимизация, 73 1 показатели, 105 регламентация, 62 сбор информации, 103 улучш ение, 91 формализация, 82 Бизнес-функция, 15 д Д екомпозиция, 18; 19 К К ачество компании, 115 п р о д у к ц и и ,92 КИСУ, 17; 20; 21; 71; 78; 125; 128 внедрение, 85 изменение требований, 103 Предметнь А А Ш 8 , 30; 31; 42; 81; 101; 102; 1 0 6 ;1 2 7 атрибуты объектов, 141 диаграммы и модели, 128 методология, 31 моделирование, 128 наименование объектов, 149 настройка, 143 приемы моделирования, 148 регламент описания БП, 156 репозитарий, 24 создание:документации, 127 создание:модели, 143; 150 типы объектов, 135 форматы моделей, 50 В ВР\Уш, 31; 81 С С А8Е-инструменты, 80 СЮ, 85; 86 обязанности, 87 требования, 87 I ШЕЕ, 31; 81 А Анкетирование, 103 Б Бенчмаркинг, 39 Бизнес-моделирование, 20; 21; 2 документирование, 100 инструменты , 80 методика, 41 методология, 99 мифы и реальность, 78 организация работ, 50 ош ибки, 97 Ши определение требований, 86 ■» построение, 23 проектирование, 26 управление персоналом, 25 К лю чевы е индикаторы, 97 К омпания бизнес-модель, 105 внутренние соглаш ения, 99 информационная политика, 86 И Т-архитектура, 124 качество потенциала, 89 обучение персонала, 102 оптимизация бизнеса, 120 ош ибки управления, 120 создание имидж а, 94 управление качеством, 113 Консультант выбор, 39 К орпоративная сеть, 84 ^ Критерий связности, 68 сцепления, 68 МСМК, 110 «Л 3%1 ш О ОМСК, 105 документирование, 107 ,, (! ^ , ,Л П П одход к управлению процессны й, 15 функциональный, 15 П оиск объ ектов, 19 П оказатель эффективности, 72 П родукция жизненный цикл, 94 Р Реинжиниринг, 15; 20; 77 С ^ М М аркетинг, 92; 93; 95 М оделирование, 30 бизнес-процессов, 29; 33 качество, 65 ответственные лица, 99 оценка качества, 66 М одель “ 20 клю чей” , 116 еЕРС, 128 адекватность, 69 управления, 16 функциональная, 28 Система менеджмента качества, 88 менеджмента качества:модульная, 110 сбалансированных показателей, 22; 23 сбалансированных показателей; разработка, 73 управления качеством, 107 Системный аналитик, 37 Стандарт ГОЕГ, 31 180 9001, 81; 90; 92 Т Т ираж ирование бизнеса, 123 Топ-менедж ер по ИТ, 85 ■ > д к 7V ' 166 У•'Чли* к - . ' * * * ! » ' «? ) >1 „р Предметный указатель

Ильин В.В. Моделирование бизнес-процессов. Практический опыт разработчика

Похожие документы

Разделы

Поддержка

Ильин В.В. Моделирование бизнес-процессов. Практический опыт разработчика

Похожие документы

Добавить этот документ в коллекции

Добавить этот документ в сохраненные

Предложите, как улучшить StudyLib