Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Записи в рубрике ‘Статьи’

(English) What CEO and CFO Should Know About Digital Transformation

Этот контент доступен на языках: English.

08.05.16 | Статьи |     Комментарии: закрыто

Процессные паттерны: планирование-исполнение (четыре варианта)

Некая организация живет по плану: на регулярной основе планы составляются, затем пункты плана выполняются.

1. Антипаттерн: планирование и исполнение в одном процессе

Проблема этой диаграммы в том, что планирование длится, пока не будут выполнены все пункты плана. » читать дальше

Процессно-проектный дуализм

Деление деятельности на проектную и процессную в действительности очень поверхностно - при ближайшем рассмотрении выясняется, что одно не существует без другого.

Как в случае проектов, так и процессов можно выделить два уровня управления:

  1. собственно управление объектом (бизнесом, компанией или ее частью)
  2. управление системой управления - будем называть это мета-управлением

Например, управление проектом строительства нового цеха заключается в том, чтобы планы были вовремя и грамотно составлены, обеспечены ресурсами, чтобы каждый знал что и когда от него требуется. Отчетность и контроль, реакция на непредвиденные отклонения и корректировка планов - рутина управления проектом… Это первый уровень управления проектами. » читать дальше

30.06.15 | Статьи | ,     Комментарии: закрыто

Концепция интегрированной среды коллективной работы

В предыдущей части мы классифицировали сложившиеся формы коллективной работы: проекты, процессы, кейсы, документооборот, инциденты. Там же было сказано, что разделить их можно лишь умозрительно, в реальности они взаимосвязаны.

Характерно, что свод знаний по проектному управлению PMBOK рассказывает не столько про проекты, столько про процессы управления проектами. В свою очередь, значительная часть свода знаний по процессному управлению CBOK посвящена проектам совершенствования бизнес-процессов.

Взаимозависимость проявляется в следующих формах: » читать дальше

19.02.15 | Статьи | ,     Комментарии: закрыто

Управление проектами, процессами и кейсами

«Специалист подобен флюсу: полнота его одностороння» – этот афоризм Козьмы Пруткова приходит на ум при близком знакомстве с некоторыми консультантами по процессному или проектному управлению. Обычно это разные люди.

Почему так получается – сообщает нам та же кладезь афоризмов: «Никто не обнимет необъятного». Времена энциклопедистов давно прошли, человеческое знание все больше специализируется и фрагментируется. Быть настоящим экспертом в нескольких областях – сложно. Теорию, положим, выучить можно, но чтобы стать практиком, надо потратить годы, а это значит попасть в колею какого-то одного подхода.

В результате, если вы разговариваете с сертифицированным руководителем проектов, то он сразу начинает с того, как следует управлять проектами и что для этого нужно. Аналогично, специалист по бизнес-процессам глядит на мир через призму процессов. Не всегда, но, как правило, это так. » читать дальше

ИТ-системы для функционального и процессного управления

В предыдущих частях (начало, продолжение) мы изложили взгляд на проектное и процессное управление как на способ компенсации органических дефектов функционального управления. Рассмотрим теперь, какие существуют инструменты (информационные системы) для поддержки функционального, проектного и процессного управления.

Начнем с функционального управления. Специализированные системы – бухгалтерские, складские, системы управления жизненным циклом изделий (PLM), системы оперативного производственного планирования (APS) и т.п. – обслуживают функции соответствующих подразделений. Исторически такие системы появились первыми, как исторически самым ранним является функциональное управление. » читать дальше

Разбираемся с процессами, проектами и функциями

В первой части мы констатировали, что разделение труда, приводя к росту производительности труда отдельного работника, одновременно порождает разобщенность между службами, которая влечет за собой снижение эффективности компании в целом.

Эти проблемы проявляются с ростом масштаба и возраста компании. Пока у руля основатели, пока размер исчисляется десятками сотрудников, наличия взаимопонимания и мотивированности у менеджеров достаточно, чтобы потери на «трение» были минимальными. Затем, например, компания приглашает нового энергичного директора по продажам, который полностью переформатирует отдел продаж. Само по себе это может и хорошо, но былого взаимопонимания с директором по производству нет, и начинаются трения, которые выплескиваются в «поиски крайнего» на планерках у директора.

Или же собственник (он же до поры до времени генеральный) решает, что бизнес наконец-то крепко стоит на ногах, и он имеет право отойти от оперативного управления и отдаться любимому серфингу. И тут в компании начинается разгул феодальной вольницы.

Какие есть варианты действий у руководителя в ситуации начинающегося раздрая? » читать дальше

03.02.15 | Статьи | ,     Комментарии: закрыто

Как разделение труда снижает производительность

Во всем виноват Адам Смит! Ведь это он изобрел разделение труда. Впрочем, есть мнение, что он его не изобрел, а лишь описал. Пусть так — в конце концов, дело не в личности, а в явлении.

Жизнь наша устроена так, что стоит найти решение какой-то проблемы, как это решение через некоторое время само становится проблемой. Вот и разделение труда, позволив повысить производительность труда в одних случаях, создало проблемы с производительностью труда в других. » читать дальше

31.01.15 | Статьи | ,     Комментарии: закрыто

Где начинается и где заканчивается процесс?

Нет, речь не о том, что процесс начинается стартовым событием и событием же завершается, это понятно. Речь о том, что считать процессом, а что нет.

Несколько цитат, демонстрирующих разброс мнений по этому вопросу -

Пол Хармон комментирует дискуссию “Process and Capabilities” в группе BPTrends на LinkedIn:

Существенное различие между практиками - одни используют термин “процесс” для обозначения диаграммы или даже в еще более узком значении - для обозначения паттернов потоков работ, а другие называют “процессом” все, что относится к получению определенного результата. Я определенно отношусь ко вторым… для меня отделение “ресурсов”, “людей” или “менеджеров” от “процесса” - это просто слишком узкий взгляд на процессы… “Способности”, о которых говорят в армии, это маленькие процессы - или действия, если хотите - которые при необходимости собираются в более крупные процессы. Высадка на резиновой лодке - одна способность, марш-бросок на 10 миль - другая, и т.д. Когда, например, возникает ситуация с заложниками, процесс (проект) комбинируется из множества отдельных действий и исполняется.

Как мы видим, Пол называет процессами буквально все - действия и комбинации действий любого масштаба, не делая разницы между процессами и проектами. » читать дальше

Что является процессом в BPMN (и что не является)

Термин “процесс” многозначен и в зависимости от контекста может означать очень разные вещи. Это создает сложность для тех, кто начинает изучать BPMN. В помощь им эта краткая заметка.

1. Процесс BPMN повторяем

Не является процессом в понимании BPMN, например “Ликвидация компании”, так как он исполняется лишь один раз. (Конечно если вы не специализируетесь на предоставлении услуг в этой области.)

2. Процесс BPMN предсказуем

Процесс может разветвляться по разным траекториям в зависимости от данных или событий, может распараллеливаться и т.п., но при этом предполагается, что все развилки нам известны, причем известны наперед - не на стадии исполнения процесса, а на стадии его проектирования.

Это сильное предположение, и не все из того, что мы называем процессами в быту, ему удовлетворяет. Например, предсказать все развилки в процессе лечения пациента, начиная с его поступления в приемный покой больницы, вряд ли возможно в принципе. Это же относится к ведению дела в суде: противная сторона может представить документ, который повернет ход процесса по сценарию, отличному от запланированного нами.

Такие последовательности действий, развивающиеся по непредсказуемым наперед сценариям, в зависимости от контекста следует трактовать как проекты или кейсы.

3. Процесс BPMN нетривиален

Если вы не можете декомпозировать процесс на несколько задач, то это, с точки зрения BPMN, не процесс. Процесс состоит из множества связанных задач и/или подпроцессов, т.е. не атомарен.

Этим же свойством - неатомарностью - обладает и подпроцесс. Разница между процессом и подпроцессом та, что процесс связан с событиями во внешней среде (он на них реагирует на старте и он их инициирует завершением), подпроцесс запускается не внешним событием, а просто потоком управления в вышестоящем подпроцессе или процессе.

4. Процесс BPMN конкретен

У процесса BPMN есть четко определенное стартовое событие, заранее определенная цепочка действий и определенные варианты завершения.

Не является процессом в понимании BPMN, например, “Бюджетный процесс”. С точки зрения BPMN, это несколько процессов (утверждение бюджета, отчетность по исполнению бюджета) плюс несколько задач, являющихся частью “чужих” процессов,  например, задача “Проверить наличия бюджета” в процессе “Закупка”.

Аналогично, “Продвижение продукции” с точки зрения BPMN - это не процесс, а семейство родственных процессов. Также не процессом, а семейством процесса являются вещи с названием “Управление чем-то”.

5. Процесс BPMN дискретен

Если в вашем процессе, предположим, на очередном этапе согласования возможен возврат к самому началу, то рассмотрите в альтернативный вариант - завершить этот экземпляр процесса и начать новый, когда и если возникнет такое желание.

Например, если процесс поиска сотрудника не дал результата, то лучше завершить процесс с соответствующим статусом, помня при этом, что при желании процесс можно будет запустить по-новой (вероятно, с другими входными данными, например, с более щедрым предложением зарплаты).

Это будет лучше с точки зрения контроля и анализа: мы честно признаем, что процесс не всегда заканчивается успехом. Также более достоверными получаются данные по продолжительности процесса.

6. Входы и выходы процесса BPMN - это, в первую очередь, события

Распространенным является взгляд на процесс как на нечто перерабатывающее входы в выходы. В такой трактовке входы и выходы - это ресурсы.

Но что касается процесса BPMN, то он реагирует на входы и порождает выходы, т.е. входы и выходы здесь - события. Входные и выходные ресурсы в BPMN моделировать тоже можно, но эта возможность опциональна, а входные и завершающие события обязательны.

Старт процесса - это всегда обработчик события, происходящего вовне, завершение - это инициатор события во внешней среде. В частном, но распространенном случае, событие может быть т.н. “пустым” (None Event), т.е. “волюнтаристским” на старте процесса или “никаким” на его завершении.

7. Процесс BPMN - это история объекта, а не субъекта

Не пытайтесь моделировать в BPMN процессы типа “Рабочий день сотрудника”.

Правильный подход - процессы типа “Прохождение клиентской заявки”.

8. Процесс BPMN не завершается, пока не выполнена вся работа

Процесс в BPMN стартует тогда, когда нам пришло в голову выполнить некую последовательность действий или когда нас на это сподвигло внешнее событие (например, клиентский заказ), и не завершается до самого конца, т.е. пока еще есть что делать (например, до завершающего звонка клиенту после отгрузки в рамках контроля качества сервиса).

“Здесь у нас процесс продажи заканчивается и начинается процесс бухгалтерии” - плохая идея, в данном случае налицо один кроссфункциональный процесс, а не два отдельных.

9. Процесс BPMN клиенто-ориентирован

Рассматривайте процесс как сквозной, ориентируйтесь не на границы между подразделениями, а на взгляд заказчика (в идеале - внешнего клиента): начните с исходного обращения заказчика и доведите процесс до выдачи заказчику ценного для него результата.

Чтобы отрешиться от привычного взгляда “изнутри наружу”, воспользуйтесь следующим приемом: попробуйте смоделировать, например, вместо процесса продажи - процесс покупки вашим заказчиком, вместо процесса рассмотрения рекламации - процесс подачи рекламации и получения на нее ответа и т.п. Выясните, что такое оптимальный процесс с точки зрения заказчика.

Внутренние ограничения на каком-то этапе проектирования процесса тоже придется учитывать, но отталкиваться лучше от взгляда на процесс со стороны заказчика.

10. Процесс BPMN - это не микро, а макро-менеджмент

Использовать BPMN для детальной регламентации деятельности на одном рабочем месте возможно, но любим мы его не за это. Если сотрудники не обучены, то это конечно проблема, но это не процессная, а функциональная проблема. И для нее существует масса решений помимо BPMN.

Процессные проблемы - это когда сотрудники функционально грамотны, т.е. нормально справляются со своими обязанностями, но процесс в целом сложен, так как требует четкого согласования усилий сотрудников из подразделений, разнесенных по иерархии и географически. При этом ответственность за передачу “эстафетной палочки” и за конечный результат размазана, что приводит к неудовлетворительной итоговой эффективности.

В решении подобных проблем BPMN незаменим, так как позволяет сделать схему взаимодействия участников процесса явной и одинаково трактуемой всеми заинтересованными сторонами - руководством, бизнес-подразделениями и “процессными технологами” (в том числе ИТ-специалистами), задача которых - воплотить эту схему в жизнь.

Copyright © 2008-2019 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии