|
rkh99GaryaНе нужно изобретать велосипед BPMN... :)
А почему именно BPMN? Почему не EPC или IDEF? И вообще причем тут моделирование БП?Это была реакция на процитированный ниже вопрос.
Я тут немного растекусь мыслью по древу, поскольку процессное управление - мой конек, я его углубленно изучал, и ниже приведу некоторые аспекты теории процессного управления.
rkh99 А вопросик в студию - что такое бизнес-процесс? Определений на самом деле много (ибо нет четкого определения самого процесса). Мне вот это определение нравится
"Бизнес-процесс - это регулярно повторяющаяся последовательность взаимосвязанных мероприятий (операций, процедур, действий), при выполнении которых используются ресурсы внешней среды, создается ценность для потребителя и выдается ему результат. У бизнес-процесса должен быть единый менеджер, который управляет процессом и отвечает за его результат."
Определений действительно очень много. Одно из базовых мне тоже не нравится - оно формулирует бизнес-процесс как элементарную функцию, этакий "черный ящик" со входами и выходами, который преобразует то что на входе в то что на выходе. По-моему, нынче такая формулировка больше подходит именно для "экшна", элементарной операции, из которых бизнес-процессы компонуются.
Ваша формулировка гораздо ближе к современному пониманию бизнес-процесса, и мне больше импонирует. Но, если вникать в детали, удачная у нее только первая половина. Со второй ее частью я не могу согласиться. Прежде всего, у бизнес-процесса есть ЦЕЛЬ. И есть СПОНСОР, который эту цель определяет. Иными словами, это инициатор процесса, по инициативе которого процесс возникает и существует как таковой.
Термин "потребитель" озвучен невнятно. Потребитель кого/чего? У процесса может быть множество разных потребителей, одни могут потреблять некие материальные продукты или информацию, которую он производит, потому что она им необходима для каких-то собственных целей, другие от него же могут получать профит в виде прибыли, образующейся от некой деятельности, третьи "потребляют" профит от сбыта ("продажи") процессу ресурсов, необходимых для его работы. Цели, которые преследуют все категории потребителей, и их интересы зачастую вступают в противоречие. Цель спонсора - лишь одна из таких целей. Но спонсор должен всегда иметь в виду, что процесс существует как таковой только в результате баланса интересов различных сторон, которые с этим процессом контактируют. Поэтому цель спонсора, как правило, комплексная - удовлетворить собственный интерес, но при этом контролируя соблюдение интересов иных сторон, взаимодействующих с процессом, чтобы соблюсти баланс интересов, который позволяет каждой из участвующих в процессе сторон получать собственную выгоду. В идеальном случае выгоды всех сторон должны хотя бы приблизительно просчитываться, ведь нарушение интересов хотя бы одной стороны может привести к сбоям в работе процесса и даже к его полной остановке.
Понятие "ценности", которую должен приносить "потребителю" процесс тоже требует дополнительной расшифровки. Вспомогательные процессы могут не иметь никакой ценности для спонсора процесса, но их работа может оказаться необходимой для обеспечения работоспособности других процессов и всей системы процессов. С позиций клиентоориентированности всей системы процессов (бизнеса) зачастую внимание акцентируется на ценности для конечного потребителя на выходе всей системы процессов. С этой позиции в Lean все процессы делятся на создающие ценность для конечного потребителя и не создающие ее - так что говорить о том, что вообще все процессы создают ценность априори, в этом смысле уже нельзя. Если исходить из концепции Lean (а она все-таки процессная), то одной из главных компонент выстраивания структуры системы является "поток создания ценности" (для конечного потребителя, а не для потребителя результатов того или иного процесса), который должен сквозняком проходить через множество процессов наряду с потоками затрат и распределения доходов. И каждый бизнес-процесс и каждая операция в этом бизнес-процессе, по идее, если речь идет именно о Lean, должна получать оценку в терминах этих трех потоков. Два из них формируют картину в терминах интересов спонсоров бизнеса, третий (поток создания ценности) в терминах интересов потребителей результатов работы бизнеса (клиентов-покупателей). Таким образом, создается хотя бы частичная картина соблюдения баланса интересов в компонентах системы всех процессов. Четвертый поток - поток затрат времени, потому что время - самый ценный ресурс. Любопытно, что в Lean зачастую заменяют поток затрат на поток времени - потому что они сильно взаимосвязаны и потому что фактические расходы весьма непросто определить для операций, по которым они "размазываются", но время всегда определимо. И именно в терминах времени и потока создания ценности, разделив получаемую долю ценности на фактически затраченное время, получают КПД процесса и каждой операции в процессе по пути потока создания ценности. И стараются этот КПД повысить на каждом участке работы всем возможными способами.
В Lean для полноты картины не хватает информации об интересах поставщиков ресурсов процесса, но наличие выше перечисленных компонентов - уже весьма существенное достижение для принятия наиболее рациональных и оперативных управленческих решений.
У бизнес-процесса действительно должен быть "процессный менеджер", который должен оперативно "следить за приборами", ориентируясь на цели и приоритеты, озвученные спонсором. Он должен следить за отклонениями и непредвиденными ситуациями и реагировать на них. В SixSigma, в "теории глубинных знаний" Деминга, в системе статистического управления качеством процесса (SPC) производится классификация процессов по параметрам управляемости, устойчивости, индекса воспроизводимости процесса и числа деффектов на млн (DPMO). Все факторы, которые могут вызывать отклонения от нормального (запланированного) хода процесса, делятся на две категории - имеющие системный характер ("особую природу", как говорил Деминг, детерминированные) и случайные. Первые возникают в силу не идеальности модели управления (модели бизнес-процессов), которая может просто не включать в себя описание реакций на влияние некоторых факторов и компонентов реальной системы, которые "забыли" включить в управленческую модель процесса, либо включили с ошибками и перекосами. На такие отклонения должны реагировать два менеджера - менеджер процесса (который оперативно должен "потушить пожар") и менеджер, которому спонсор доверил управление изменениями (чтобы подобных "пожаров" больше не возникало). Второй должен вносить изменения в структуру процесса по каждому выявленному фактору отклонений, имеющему системную (предсказуемую) природу.
По принципу "хопана!" за один прием сразу же модель процессов, совершенно соответствующую реальному положению дел, в принципе невозможно. Как невозможно "с нуля" сесть на велосипед и сразу же поехать - нужно сначала "отладить" и "автоматизировать" реакции на отклонения. Затевающие внедрение ERP-систем зачастую этого не понимают. Отсюда и возникают провальные проекты по внедрению ERP-систем - потому что ожидания были "нам сейчас подгонят велосипед, мы на него сейчас сядем и сразу же поедем".
После устранения всех системных факторов борьба с отклонениями продолжается - с теми, которые носят случайный характер с тем чтобы, по возможности, уменьшить несистемные отклонения. Если сравнивать с технологическими процессами (принципы управления которыми те же, что и бизнес-процессами), то стараются заменить оборудование на такое, которое позволяет достигать более высокой точности обработки, уменьшив допуски и посадки. А также преобразованием случайных отклонений в системные, которые включаются в модель. Например, если участники процесса, взаимосвязанные между собой, случайным образом выходят покурить (ну, организм у них требует), то процесс может простаивать потому что то один вышел покурить, то другой, то третий. В систему вносится жесткое расписание перекуров, и покурить все выводятся по расписанию одновременно - так три простоя (отклонения) сокращаются до одного.
Управляемый и устойчивый процесс, должен получается после предварительной длительной работы с изменениями с уже работающим процессом. Поэтому так важно, чтобы процесс был способен к изменениям, а не быть "застывшим в бетоне".
rkh99GaryaНе нужно изобретать велосипед BPMN... :)
А почему именно BPMN? Почему не EPC или IDEF? И вообще причем тут моделирование БП?Потому что эта нотация ориентирована не на "нарисовать и положить в стол", а на синтез реально работающей системы процессов. Наиболее существенный фактор, на котором концентрирует внимание по этой причине BPMN, - ритм процесса, а не "по направлениям бухгалтерского учета". Есть события, порождающие "длинную транзацию" (или "экземлпяр" процесса), и у разных процессов это могут быть разные события. Самая основная причина, по которой процесс приема на работу сотрудников нельзя делать частью процесса в котором эти сотрудники задействованы - у них РАЗНЫЙ РИТМ . В одном ритме работают операции, которые "передают воздействие по цепочке", которое может распараллелиться, соединиться обратно, но главное - они работают в одном ритме, и связь между последовательностью операций в них жесткая. Из таких "жестких" последовательностей выстраивается схема в "оркестровке" процесса. А взаимодействие между процессами, работающими относительно независимо друг от друга, описываются "хореографией", в которой фиксируются "слабые" взаимодействия и взаимодействия в асинхронном режиме.
Поясню на понятном примере. Выточка детали на станке может выглядеть как часть процесса производства, но процесс производства завязан на производственные заказы, которые в свою очередь завязаны с заказами покупателей и/или заказами управляющих менеджеров на пополнение остатков номенклатуры готовой продукции исходя из принципов статистического управления запасами и теории массового обслуживания. Сам станок работает в ритме установил деталь - обработал - выплюнул - установил следующую. Этот ритм никак не связан с производственными заказами, либо с заказами покупателей. Он определяется изначально конструкцией станка. Для того чтобы детали попадали на следующий участок, их нужно туда доставлять, но доставлять каждую деталь в отдельности не всегда рационально. У операции транспортировки деталей от участка у участку - свой ритм, и он определяется совокупностью неких факторов, определяемых в других процессах - сколько полуфабрикатов наточил станок на входе в своем ритме и какой крайний срок передачи заготовок по плану производственных заказов, который работает в своем ритме. Есть еще процесс переналадки станков под изготовление той или иной детали - и у него тоже свой ритм. И он тоже завязан на факторы других процессов, но НЕ НЕПОСРЕДСТВЕННО. Это - "слабая связь" между процессами, посредством таких связей процессы взаимодействуют друг с другом, работая каждый в собственном ритме.
Если исходить из базовых принципов процессного подхода, нужно идти "от конца ко входу" всей системы. Сначала определить ключевые процессы, сформулировать их цели и, что весьма существенно, описать события, на которые они реагируют - они определяют их ритм. Понять, какие процессы взаимодействуют с этими процессами и почему, какой у них ритм - и выделить их в отдельные процессы. Определить для каждого процесса цель, параметры качества и события, порождающие в нем "экземпляры длинных транзакций".
Длинная транзакция - это некая "обработка события", которое возникает на входе процесса и заканчивается на его выходе. Одновременно могут обрабатываться большое количество транзакций, они могут находиться на разных фазах обработки в системе. Но у каждой обработки должен существует четко обозначенное событие, которое такую обработку породило, и четко обозначенный конец, до достижения которого обработка считается НЕ завершенной, и потому ожидающей неких действий на последующих фазах процесса, в отличие от уже выполненных транзакций, которые уже ничего не ожидают, и используются только для анализа статистики и параметров качества процесса.
Для каждого процесса должны быть определены параметры качества, которые в итоге образуют иерархию системы KPI.
* * *
Обязательно должно быть управление изменениями, иначе все эти показатели - лишь для "посмотрели и развели руками".
Концентрировать внимание только на автоматизации управления одними только процессами, по-моему, неправильно.
Есть три вида деятельности на любом предприятии:
- процессы - упорядоченные повторяющиеся последовательности регламентированных операций
- задачи - несистематизированные операции, которые требуют обработки и их контроля
- проекты - упорядоченные НЕповторяющиеся (однократные) последовательности регламентированных операций
В общем случае все они могут порождать друг друга и могут использовать одни и те же ресурсы (в частности, работников). По этой причине фиксировать только некоторую часть деятельности не совсем корректно - многое упускается. И при кажущейся недогруженности некоего ресурса в одной из систем (управления процессами) реально он может быть перегружен "задачами" или "проектами". Потому управление ресурсами не будет эффективным, если все три вида деятельности не охвачены. А при взаимодействии всех трех видов деятельности неизбежно часть ресурсов оказывается задействованной в их совокупности.
Процесс мониторинга рынка и маркетинговых исследований может привести к выводу о необходимости запуска на рынок нового вида продукции с новыми параметрами. Проработка целесообразности может породить ряд трудно формализуемых задач , которые должны выполнить отдельные сотрудники (уточнить детали возможного дополнительного использования новых технологий, например). После принятия положительного решения происходит порождение проекта разработки конструкторской, технологической документации, интеграции новых процессов в существующее производство. Проект по мере его выполнения порождает новые процессы , либо вносит изменения в старые посредством процесса управления изменениями уже выполняющихся процессов .
Интеграция изменений в существующие процессы - очень важный вопрос, который зачастую игнорируется. Я убежден, что масштабные изменения нельзя производить одним махом, как это сложилось в устаревшем понимании "водопадного" управления проектами. Такой подход чреват высокими рисками просто порушить бизнес, или, как минимум, совершить существенные финансовые вложения не в улучшения, а в ухудшения существующей системы управления. Новые подходы Agile - постепенных изменений, соответствуют концепции довольно давно применявшехся практик Кайдзен-развертывания, постоянных мелких улучшений. На них нужно ориентироваться, а не на "внедрение, которое начинается завтра и должно закончиться вот тогда-то по плану, заранее разработанному на несколько лет и якобы уже всё учитывающему". А на самом деле не учитывающему очень многого, потому что людям свойственно ошибаться и потому что они не боги.
И, ПМСМ, все усилия должны быть направлены именно на плавную-постепенную интеграцию новых принципов более оптимального автоматизированного управления в уже существующую систему - мелкими шагами, без радикальной ломки того, что сейчас, может быть, и не очень оптимально, но работает. Хорошая система автоматизации должна предоставлять именно такой подход - мелких постепенных изменений, постепенной регламентации и уточнения того, что ранее не было регламентировано и включено в модель. А не спроектировали, отлили в бетоне, бетон застыл, после чего выясняется, что форма должна была быть несколько другой, поэтому нужно браться за бетонодробилки и рисковать обрушить всю конструкцию, от любого сколь-нибудь значительного удара отбойным молотком.
|
