1. От сбыта товаров к массовому выполнению заказов «Не товары, а процессы их создания
приносят компаниям долгосрочный успех»
М.Чампи, Дж.Хаммер Сегодня уже никем не оспаривается переориентация бизнеса на запросы клиентов. Но, по существу, это означает переход от стратегии сбыта товаров к стратегии массового ВЫполнения заказов. Будущее — за качественно новым взаимодействием технологических и бизнес-процессов. Чтобы эффективно выполнять большое количество заказов, нужен отлаженный процесс взаимоотношений между компанией и заказчиками, а также эффективные действия сотрудников по выполнению заказов. Организация эффективной работы персонала является условием успеха большинства компаний. При нехватке квалифицированных кадров решение этого вопроса становится условием выживания. Компании тратят много ресурсов на поиск и удержание хороших специалистов, вместо того чтобы поднять продуктивность существующих сотрудников. Ключом к решению этой проблемы является создание системы управления бизнес-процессом предприятия, гибкой и развивающейся вместе с бизнесом. 2. От информационной системы к автоматизированной системе управления бизнес-процессом «Информационные технологии – не самоцель, а средство
улучшения промышленных и социальных технологий»
Владимир Паронджанов Информационные системы в большинстве случаев представляют собой «корпоративную записную книжку», в которую сотрудники вносят данные. Результаты обработки этих данных предоставляются системой в виде отчётов в интересах различных служб: бухгалтерской, складской, маркетинговой и других. Автоматизированная система при процессном управлении предприятием, кроме функций обычной информационной системы, вырабатывает управляющие сигналы в соответствии с логикой, заложенной в неё бизнес-моделью. Сотрудники по полученным сигналам выполняют действия, предусмотренные описанием бизнес-процесса.Таким образом, автоматизированная система становится активной по отношению к людям, участвующим в бизнес-процессе, то есть управляющей. Организация бизнес-процесса — всегда творческий акт предпринимателя или директора компании. Одинаковых бизнес-процессов даже в одной сфере бизнеса быть не может. У каждого предприятия своя клиентура, свои поставщики, свой расклад сотрудников. А это значит – другие взаимоотношения, и, следовательно, другой деловой процесс. Уникальность этого процесса часто является конкурентным преимуществом всего предприятия. И именно эта уникальность является основной сложностью на пути повсеместной автоматизации бизнес-процессов. В каждом случае требуются разработка описания бизнес-процесса и кропотливая настройка программного обеспечения в соответствии с ним. 3. В чём проблема? «Учёный, ты объясняешь нам науку,
но кто объяснит нам твоё объяснение»
Джордж Байрон Первоочередной задачей при внедрении процессного управления является описание бизнес-процессов. Не сделав корректного описания, бессмысленно управлять бизнес-процессом, а уж тем более его автоматизировать. Деловые процессы нужно отразить в форме, понятной для всех заинтересованных лиц: для владельца бизнес-процесса, для непосредственных исполнителей процесса и для разработчиков автоматизированной системы управления. Так в чём же проблема? Она стара, как мир: владелец процесса рассказал, как должно быть, и видел при этом одно, разработчик автоматизированной системы из рассказа понял и формализовал другое, а исполнители процесса делают, как умеют. Достижение взаимопонимания – тяжёлый и сложный интеллектуальный труд, производительность которого крайне низка. Так как проблема эта очень старая, то решают её уже давно. Метод решения заключается в том, чтобы предложить заинтересованным лицам специальный язык, позволяющий всем однозначно понимать суть бизнес-операций. В нашем случае, из всех заинтересованных лиц самым "продвинутым" в смысле формализации знаний, конечно, являются разработчики автоматизированных систем. Уж сколько ими придумано разных формальных языков со времён Алгола и Кобола! 4. Как много языков хороших... «Язык представляет собой одно из главнейших орудий мысли….
Несовершенство этого орудия … мешает делу
и уничтожает всякое доверие к его результатам»
Джон Стюарт Милль Сегодня наиболее известными языками моделирования процессов являются IDEF(Integrated Definition Function Modeling), UML(Unified Modeling Language), ARIS и ряд других. Ограничимся кратким знакомством с первым из них. В ходе компьютеризации производства аэрокосмической промышленности США была выявлена потребность в разработке метода описания процессов в производственных системах. Для удовлетворения этой потребности была разработана методология IDEF, которая в настоящее время принята в США в качестве федерального стандарта. В основе метода лежит принцип иерархической декомпозиции и ключевым является понятие блока, который отображает некоторую функцию. Четыре стороны блока играют разные роли: левая сторона имеет значение «входа», правая – «выхода», верхняя – «управления», нижняя – «исполнителя». Существует программа BPwin, которая позволяет быстро рисовать схемы в стандарте IDEF и обеспечивает вложенность одних блоков в другие. Разрабатывая этот метод для описания, в основном, технологических процессов, их создатели не предполагали, что правила композиции бизнес-процессов имеют свои существенные особенности. Визуальное восприятие процессов с развитыми «горизонтальными» связями становится очень неудобным. Кроме этого, функциональных блоков на одной странице можно разместить максимум 5. Поэтому даже самые простенькие бизнес-процессы получаются на 10 листах формата А4. Вот представьте, что эту стопку листов приносят директору – утвердите, пожалуйста, и подпишите. Директор должен, постоянно листая взад и вперёд, поочерёдно прочитать, понять и запомнить фрагменты схемы, найти и мысленно соединить все оборванные стрелки. После этого его мозг должен склеить фрагменты в единый логичный образ. 95% времени уходит на сборку «пазлов» и только 5% — на анализ содержания. Человек, управляющий бизнес-процессом, ничего от этого метода не выигрывает.
В равной мере это мнение относится к UML и ARIS. Сравнению этих языков посвящено много публикаций. Мы присоединимся к мнению В.В. Репина, Заведующего кафедрой Управления бизнес-процессами Института Экономики и Финансов в РЭА им. Плеханова, эксперта ООО «ФИНЭКСПЕРТ.РУ». В частности он пишет: «... как показал наш опыт, модели процессов, построенные в BPwin, вызывают трудности при понимании их специалистами предметной области. Это приводит к тому, что они становятся пассивными слушателями при обсуждении описания бизнес-процессов и им по существу навязывается понимание бизнес-процессов аналитиками. Ошибки неправильного описания бизнес-процессов затем выявляются, к сожалению, на более поздних этапах разработки...» [2]. 5. Почему нельзя жить по старому? Надо признать, что несмотря на все усилия разработчиков формальных языков, большинство владельцев бизнес-процессов так и не научились ими пользоваться. Как следствие, они оказались отстранёнными от плодотворного взаимодействия с программным обеспечением, что ощутимо снижает эффективность работы предприятий. До сих пор описание бизнес-процессов, и тем более разработка программного обеспечения в соответствии с этим описанием, считается интеллектуально сложной и трудоемкой задачей. Для её решения нужен коллектив специалистов: консультантов-аналитиков, специалистов по бизнес-моделированию, разработчиков программ и др. При этом возникает ряд совсем не простых вопросов. Существует ли гарантия того, что в результате получится то, что замыслил владелец бизнес-процесса? Что делать, если через некоторое время придётся менять процесс? Как система будет воспринята исполнителями бизнес-процесса? Конечно, существуют компании, которые всегда смогут найти группу интеллектуалов, способных преодолеть любые сложности. Однако наступление эры всеобщей автоматизации бизнес-процессов потребовало других подходов. 6. Что делать? «Процесс формализации профессиональных знаний… -
исторически новая форма интеллектуальной деятельности»
Григорий Громов Мы полагаем, что владелец бизнес-процесса – ключевая фигура в разработке и управлении бизнес-процессом. Он может и должен формализовать свое знание процесса самостоятельно. Это означает, что модель бизнес-процесса должна представлять собой обычное повествование, построенное по правилам естественного языка, а не языка структурного программирования. Это позволит устранить ненужных посредников при формализации знаний, избежать ошибок типа «испорченный телефон» и, главное, обеспечит в дальнейшем возможность совершенствования бизнес-процесса со стороны его владельца. При этом бизнес-модель должна быть достаточно информативной для целей дальнейшей автоматизации. Нужен механизм (engine – «движок») для исполнения бизнес-процессов, который однозначно интерпретировал бы модель. После загрузки в такой «движок» описания бизнес-процесса автоматизированная система управления автоматически начнет работать в соответствии с этим описанием. 7. Мы это сделали! «Индустрии программирования необходимо чудо –
чудо, которое воплотило бы в жизнь мечту
о быстрой и лёгкой разработке программ»
Том Мануэль Сотрудники компании GPR автоматизировали в той или иной степени около 150 бизнес-процессов различных предприятий, ориентированных на массовое выполнение заказов. Каждый проект предполагал предварительное изучение и описание бизнес-процесса предприятия, совместно с руководителями предприятий. В ходе этой работы постепенно выкристаллизовался свой метод описания бизнес-процессов, а затем и концепция автоматизации, реализованная в программном продукте CLIENTmanager. CLIENTmanager предназначен для автоматизации деятельности относительно небольшого коллектива сотрудников в соответствии с довольно сложным бизнес-процессом. Функциональность программы нацелена на эффективное взаимодействие всех участников бизнес-процесса в ходе совершения сделок и выполнения заказов. Именно поэтому он позиционируется как CRM система (Customer Relationship Management system). Большинство руководителей при попытках объяснить свои бизнес-процессы использовали понятие документа – договор, акт, счёт, запрос, предложение, заказ, наряд и т.д. Поэтому и мы отказались абстрактных функциональных блоков и в качестве ключевого понятия при описании бизнес-процессов стали применять понятие документа. В общем случае, документом может быть любая информация, предполагающая выполнение сотрудниками определённых действий. Каждая бизнес-операция фиксируется тем или иным документом. В зависимости от выполненных действий документу присваивается тот или иной статус, который фиксирует состояние документа. Изменение статуса документа служит управляющим сигналом для включения того или иного алгоритма обработки и направления документа другим сотрудникам в соответствии с описанием бизнес-процесса. Таким образом, вся деятельность фирмы отображается в документах: все процессы порождают свои документы и используют документы, возникающие в ходе других процессов. Деловые взаимоотношения с заказчиками и действия сотрудников по выполнению заказа представляются как естественная цепочка документов-операций. Разнообразные документы, ежедневно создаваемые и получаемые сотрудниками, становятся базой для последующего анализа деятельности в самых различных разрезах. Документ, кроме действий, предполагает также определённую форму представления информации. Автоматическое создание коммерческих документов в CLIENTmanager позволяет экономить массу времени, которое сотрудники тратят при калькуляции заказов, спецификаций, счетов, при составлении коммерческих предложений, договоров, накладных и т.д. Для реализации такого подхода бизнес-процесс должен быть описан в виде последовательности текстовых предложений. Каждое предложение описывает одно действие и содержит ответы на вопросы: · Что является инициирующим событием для выполнения действия? · Кто выполняет действие? · Что является источником информации для выполнения действия? · Суть самого действия. · Какой статус какого документа фиксирует действие? · Кому направить документ и какую обработку выполнить. CLIENTmanager является инструментом для составления такого описания и, одновременно, механизмом его реализации. В нем есть интерфейс, который позволяет легко формировать последовательность таких предложений и распечатывать в виде документа, который содержит существенную часть должностных инструкций сотрудников. Загрузив такое описание в CLIENTmanager, можно стразу посмотреть, как работает ваша автоматизированная система. Интегрированный в CLIENTmanager так называемый CASE-инструмент сразу модифицирует интерфейс и логику работы программы в соответствии с описанием бизнес-процесса. Конечно, набор средств в CLIENTmanager ограничен. С их помощью нельзя автоматизировать любой процесс с любой степенью детализации. И это – не недостаток данной технологии, а наше осознанное решение ограничить сложность описания бизнес-процессов, провести границу между деловыми и технологическими процессами, между тем, что делает владелец процесса, а что – исполнители. Для реализации нестандартных алгоритмов обработки данных, предусмотрена возможность подключения внешних утилит. Обращение к ним происходит в момент присвоения документу определённого статуса. 8. Визуальное представление бизнес-процесса «Удачный рисунок иногда не только позволяет сделать наглядной и понятной
суть сложного вопроса, но нередко способен подсказать принципиально новое
соображение, идею, гипотезу, которые без такого рисунка просто не приходят в голову»
Александр Зенкин Говорят, один рисунок стоит тысячи слов, и это действительно так при условии, что рисунок хороший. Неумелое использование схем и рисунков может принести только вред. Мы пробовали изобразить описание бизнес-процесса различными способами, и, в конце концов, остановились на перекрёстно-функциональной диаграмме (Cross Functional Flowchart). Например, визуализация процесса взаимодействия менеджера, дизайнера и технолога в рамках выполнения заказа, выглядит так. Действия одного сотрудника в рамках одной бизнес-операции отображаются отдельной табличкой. В первой строке таблички – название документа, во второй строке – исполнитель, в последующих строках – статусы документа, которые фиксируют действия исполнителя в рамках данной операции. Статусы на белом фоне могут присваиваться самим исполнителем, на желтом фоне – сигнал об изменении статуса другим сотрудником. Красная стрелка определяет связь с документом-источником, синяя - показывает направление документа другому сотруднику. С помощью предложенного метода можно представлять большинство реальных бизнес-процессов на одной диасцене. В результате дополнения текстового описания бизнес-процесса такой схемой мы получаем документ, понятный владельцу бизнес-процесса и однозначно интерпретируемый системой CLIENTmanager. 9. Вместо заключения Принято считать описание бизнес-процессов сложной и трудоемкой задачей. Кроме того, для подавляющего большинства предприятий сама постановка этой задачи является абсолютно новой. Отсюда делается вывод, что предприятия своими силами не в состоянии разработать свою бизнес-модель и уж тем более её автоматизировать. Теперь вы знаете цельную и апробированную технологию, которая позволяет владельцу самостоятельно описывать, автоматизировать и управлять своим бизнес-процессом.
|
