Литература:
Автор: Андрей Гордиенко
Источник: www.sql.ru/forum/actualutils.aspx
Изменчивость БП - это очень важное их свойство, одно из ключевых в процессном управлении. Наличие постоянных изменений, оптимизирующих процесс, является, возможно, самой главной компонентой процессного подхода. В концепции TQM, в стандартах серии ISO:2000-2001 оговаривается обязательное наличие "процесса над процессами", то есть, формализованного процесса оптимизации всех остальных процессов, который вписывается в идеологию цикла PDCA (цикла Шухарта-Деминга). В российской СМК всё аутентично западным стандартам ISO, рекомендую заглянуть в ГОСТ Р ИСО 9004-2001 "Системы менеджмента качества. Рекомендации по улучшению деятельности" и ГОСТ Р ИСО/ТО 10014-2005 "Руководство по управлению экономикой качества." В концепции Six Sigma существует аналогичный цикл, только называется иначе - циклом DMAIC, но по сути это то же самое, что PDCA. В Lean и Кайдзен вы неизбежно столкнетесь с аналогами подобных циклов и отдельных компонентов, в частности, с методами устранения "муда" для целей SMED (в JIT "STEP") - сверхбыстрой переналадки оборудования. Статистические методы управления качеством в концепциях TQM и Six Sigma предполагают регистрацию ключевых параметров качества процесса и отслеживание отклонений контролируемого параметра за пределы соответствующего количества сигм процесса (в TPS это делалось с помощью карт Шухарта). Отклонения обрабатываются разными способами, могут обрабатываться каждое (инициируется процедура RCA - выявление коренных причин), либо статистическими методами обрабатывается некая совокупность отклонений для того, чтобы выявить корреляции этих причин со всевозможными потенциальными факторами (для чего применяется специальные математические методы, к примеру, многофакторный анализ). В соответствии с идеями Деминга (его "теорией глубинных знаний") все отклонения в обязательном порядке должны классифицироваться на две основные группы - на имеющие "особую" (системную) причину и на случайные, связанные с изначальной вариативностью параметров операций, которая при этом все равно требует оценки (в "сигмах" процесса). На первых фазах еще "не устаканившийся" процесс приводят к состоянию "статистической управляемости", устраняя основную массу "особых" (системных) причин, вызывающих первую категорию отклонений. При этом зачастую в схеме БП устранятся системные ошибки, например, неучет моделью БП неких важных факторов, в результате происходит "подгонка" модели БП под то, что на самом деле работает "в реальности". После того, как процесс доведен до состояния "статистической управляемости", он получает оценку в сигмах, и переходят к постоянной работе над увеличением сигмы процесса (то есть, над уменьшением неких базовых параметров, от которых зависит вариативность параметров). Это те способы, которые доминируют в Six Sigma и в TQM. Есть еще масса частных методов, которые с успехом применяются во всех процессных концепциях сразу, в частности, методов Тагути "робастной оптимизации процессов", который применялся чаще всего японцами, но базируется на тех же принципах, что и статистические методы оптимизации в TQM и Six Sigma. Всё это я говорю для того, чтобы Вы поняли, насколько важным практически во всех концепциях процессного управления считается налаженность процесса оптимизирующих изменений. Один из классиков процессного управления, Майл Вейдер, одной из главных ошибок считает "Построение Системы, не обладающей необходимой гибкостью", опять же подчеркивая необходимость регулярных изменений.
Следует, однако, заметить, что в разных концепциях отношение к регулярности изменений существенно различается. Наиболее радикальное отношение высказывается в концепции Кайдзен, которая утверждает, что изменения должны быть "каждодневными". В практике Six Sigma основные циклы улучшающих изменений имеют периодичность полгода-год - это длительность "микропроектов", над которыми работают черные и зеленые пояса ("черные пояса" - это освобожденные от иных обязанностей сотрудники СМК, "зеленые пояса" - не освобожденные, но принимающие активное участие в организации проектов в цикле DMAIC).
Надеюсь, мне удалось Вас немного напугать... (к'нерес, ахпер) :). А теперь расскажу "по-человечески" о тех изменениях, которые, как правило, дают хороший результат при внедрении BPM с использованием BPMS. Сначала Вы имеете некоторую систему, которая в существенной степени управляется "сама собой", либо "никем". О том, что она из себя представляет, высшее руководство имеет очень обобщенные представления (с отфильтрованными деталями, которые на самом деле имеют важное значение). А ответственные за конкретный участок работы знают только свой участок. В конечном итоге получается, что Систему в целом не знает вообще никто. Поэтому первое, что происходит при внедрении BPM, это формализация процесса, попытка задокументировать систему. Точнее, попыткИ (потому что с первого казачьего наскока задокументрировать можно только модели процессов только с содержанием в ней весьма грубых ошибок). Поэтому процессы изначально прописываются укрупненно, без детализации. Всё как работало, примерно так и продолжает работать, только в описанном состоянии, только и всего! :) Как команды подавались "голосом", так они и подаются, только в ключевых фазах в BPMS регистрируются факты подачи таких команд. Автоматизация процессов управления на этой фазе может быть очень низкой - но это стартовое состояние. Самое главное, оно позволяет начать регистрировать в BPMS информацию, которая прежде была только в головах, причем во множестве разных голов, и всегда разбитой на части, а теперь в одном месте. Как только БП запустили в BPMS на выполнение, вы начинаете фиксировать все сбои, отклонения, проблемы. И можете анализировать их статистику уже не на уровне "ощущений", а глазами глядя на статистические данные. Только получив эту, самую первую, возможность, гендир уже сможет сделать массу очень верных телодвижений по устранению системных проблем.
Далее происходит довольно долгая (если не сказать "бесконечная") фаза постепенной детализации описанных процессов. Вот для того, чтобы иметь возможность постепенно детализировать схемы БП, и нужна "сверхгибкость" BPMS, потому что детализируются те процессы, которые в ней УЖЕ ИСПОЛНЯЮТСЯ. На одном из наших заводов изначально укрупненно описанный процесс (в BPM-системе UNIFY NXJ) содержал порядка 12-15 укрупненных операций. В процессе постепенной (каждодневной!) детализации количество операций было увеличено более чем в 10 раз за три месяца - при уже запущенном в работу процессе! Такая детализация постепенно уточняет описание системы и приводит к выявлению и устранению системных проблем, возникающих локально. И опять в BPMS всё регистрируется, всё более и более детально.
К основным процессам в процессе такой детализации вы постепенно прописываете вспомогательные, которые с ними взаимодействуют. К вспомогательным - дважды вспомогательные... И так далее, пока не опишите с достаточной степенью детализации весь бизнес. Наверняка на это уйдет не один год. Но вы не будете испытывать никаких стрессов, которые могут завести бизнес в тупик и поставить его на грань выживания. Каждая модификация процесса не делает ничего революционного, она лишь описывает еще не описанное, и всё! Далее идет длительная работа над устранением ошибок в описании. Разумеется, на этой фазе вы столкнетесь с множественными расхождениями в представлениях различных руководителей о том, каким образом работает или должен работать процесс. Наверняка столкнетесь с конфликтами интересов, с попытками спихнуть ответственность за что-либо с себя и повесить ее на кого-нибудь другого (который отвечает совершенно симметричным стремлением). Вот тут уже потребуется воля гендира, на стол перед которым выкладывается видением первого, второго и третьего, гендир чешет репу и говорит "будет по-четвертому, исполняйте", и сказанное сразу вносится в схему. Если гендир при этом недооценил какие-либо потенциальные проблемы (гендиры тоже люди, которые обладают способностью ошибаться), мы получим проблемы, которые фиксируются BPMS. Можно вернуть эти проблемы гендиру, чтобы он вник в их причины и внес коррективы в ранее принятое решение, либо вставил пистон тому, кто намеренно такие проблемы создает, тихо саботируя принятое решение.
Вот этим и придется заниматься, внедряя BPM с опорой на BPMS... Этим придется заниматься долго и нудно - много лет. При этом предприятие будет ПОСТЕПЕННО устранять проблемы, что сделает оптимизацию бизнеса безболезненной для нее. Это ключевое отличие от однократного и масштабного реинжиниринга БП, которое, наверняка будет очень болезненным и которое опять же наверняка будет проведено с ошибками, которые никто не планирует устранять.
Когда вы опишете достаточно детально все БП, вы уже получите такое представление о системе, на некотором новом качественном уровне, о котором прежде даже не мечтали. С этого момента вы выйдите на новый уровень зрелости бизнеса. Но не высший... Потому что оптимизация бизнеса на этом не закончится. Вы сможете фиксировать в системе все ключевые параметры эффективности (KPI). Надо будет тщательно подумать над структурой таких показателей, над их иерархией, и когда система описывает, по меньшей мере, основные процессы, вы уже можете прикрутить к ней какое-нибудь ETL-решение и предоставить гендиру и другим разным топам возможность быстро ориентироваться в огромной совокупности текущих взаимодействий, требующих их внимания, которое на некой "приборной панели" будет красным показывать то место, которое требует их внимания. И избавит их от вмешательство в те процессы, которые прекрасно работают и без их участия.
После того, как вы получили зрелую систему KPI и регистрируете соответствующую статистику, вы можете продолжить оптимизировать модель, уже методами математической статистики выявляя системные причины отклонений таких показателей от нормы. И на этой фазе вы выловите еще целый траулер мелких системных проблем, которые не были видны "невооруженным глазом". После того, как вы проведете еще и эту работу (на нее тоже уйдет несколько лет, я полагаю), вы сможете считать все свои процессы доведенные до состояния "статистической управляемости". И с этого момента можете оценить их в сигмах и работать уже над увеличением числа сигм. А вот этим можно заниматься уже до бесконечности... :)
