Давайте в нашей статье отталкиваться от стандартных определений:
- Бизнес-процесс – устойчивая, целенаправленная совокупность взаимосвязанных видов деятельности, которая преобразует входы в выходы, представляющие ценность для потребителя (CBOK).
- Проект – временное предприятие, направленное на создание уникальных продуктов, услуг или результатов (PMBOK).
В самих определениях процесса и проекта содержатся противоречия: процесс – это «повторяющиеся» действия, а проект – действия, «создающие уникальный результат», следовательно, неповторяющиеся.
Но есть пара нюансов:
1. В мире есть не только черное и белое, но и 50 оттенков серого.
Существуют виды деятельности, которые являются на 100% бизнес-процессами, например: розничные продажи, типовые закупки, уборка территории, поточное производство и др. Существуют виды деятельности, которые на 100% являются проектами, например: проектирование и строительство уникального моста, подготовка миссии на Марс и др.
Одновременно с этим существуют и успешно развиваются виды деятельности, бизнесы и целые отрасли, которые обладают признаками и процессов, и проектов – находятся где-то посередине, или в области от 20 до 80 по шкале Процесс-Проект. Наиболее яркими представителями таких «промежуточных» видов деятельности являются строительство и разработка ПО.
Применение и степень внедрения той или иной практики или методологии зависит от объекта: строительство уникального моста – на 100% проект, строительство очередного типового дома – больше процесс. Кстати, подготовка сто первой миссии на Марс будет уже ближе к процессу.
2. Процессный подход и проектный подход – это всего лишь модели реального мира (деятельности). И если объект в реальном мире обладает свойствами обеих моделей, то ничего не мешает построить для этого объекта обе модели и использовать их.
Еще один интересный пример – свет. Ученые долго спорили: свет – это волна или частицы? В результате споров осознали, что и волновая теория, и корпускулярная – это лишь модели, и сейчас свет рассматривается как поток фотонов при расчетах фотоэффектов и как волна при расчетах интерференции, дифракции и т.п. Называется это «корпускулярно-волновой дуализм».
Значит, к ряду видов деятельности можно применять и процессный и проектный подход одновременно и задача эффективного управленца – уметь применять на практике и сочетать подходы и методологии для достижения максимального результата.
Пример и важный вывод
Допустим, у нас есть проект строительства дома П-44 по адресу Шелковское шоссе, 44. С точки зрения руководителя проекта (РП) – это однозначно проект. РП нужно в срок, с надлежавшим качеством и в рамках бюджета закончить работы и получить бонус.
Для простоты будем рассматривать 3 блока работ: «Проектирование», «Строительство» и «Передачу в эксплуатацию» (да простят меня строители за такое упрощение).
С точки зрения проектировщиков, строителей и стройконтроля – это «очередной дом спроектировать/построить/передать в эксплуатацию», то есть «устойчивая, целенаправленная деятельность, которая преобразует входы в выходы» = процесс.
Как это согласуется? Для ответа на этот вопрос воспользуется еще одним понятием процессного управления. Экземпляр процесса – деятельность по выполнению совокупности операций процесса, обеспечивающая получение единичного результата процесса.
Пример: обработка заявки на кредит от Петрова И.И. на ХХХ рублей – это конкретный экземпляр БП «Потребительское Кредитование». Заявка того же Петрова И.И., поданная через 5 мин (даже с теми же условиями), – это еще один отдельный экземпляр БП «Потребительское Кредитование».
Возвращаясь к примеру со строительством: для проектировщика проектирование дома П-44 по Щелковскому шоссе, 44 – это один экземпляр, а дома П111М по Киевскому шоссе, 35 – уже другой примерно равнозначный экземпляр процесса «Проектирование»… То же самое со строительно-монтажными работами. В то время как для РП, о котором мы говорили выше, важно только проектирование и строительство дома П-44 по Щелковскому шоссе, 44.
Мы приходим к выводу: для видов деятельности, являющихся «промежуточными», которые рассматриваются и как проекты, и как процессы, проект является совокупностью связанных экземпляров процессов.
Резюме
1. Ряд видов деятельности, являющихся «промежуточными», мы можем рассматривать и с проектной, и с процессной точек зрения, получая выгоды каждой из них:
- Рассматривая как проект – получаем контроль за цепочкой работ, единую ответственность за результат проекта и др.
- Рассматривая как процессы – у нас появляются возможности применения всего арсенала инструментов процессного управления – описание БП, анализ, оптимизация и регламентация БП.
2. Проект в таких случаях является совокупностью связанных экземпляров процессов.
Фото в анонсе: freepik.com
Также читайте:
Олег, пока вопросы к Вам те же, что уже неоднократно задавались: зачем менеджеру проекта описывать конкретный проект в терминах из другой области? Чем это ему поможет? Как облегчит ему жизнь? Повысит шансы на успех?
В PM достаточно инструментов и неплохо детализированные методологии управления, не только PMBoK. Менеджер проекта может использовать любые, главное - успех проекта в соответствии с принятыми заказчиком критериями.
Видел. И перечисленные выше, и подобные с точки зрения функционала.
План проекта - это не дерево. Граф (сетевой график) с весами, если угодно, который часто используется для иллюстраций в статьях по PM.
Мы включаем в календарный (!) план для каждой задачи (работы) ее описание, оценку времени выполнения, ресурсы, связь с другими задачами, ограничения и зависимости (не ранее, не позднее, после, перед ...). Это достаточно интеллектуальная деятельность.
Если какие-то задачи не образуют цикл (зачем бы это) - и ладно. Такой отдельной цели нет и быть не может.
PDCA может быть в голове у менеджера проекта, помимо прочего, если это ему зачем-то нужно. Формально это не требуется, не таблица умножения. PDCA для PM отдельно, но с примерами будет легче.
Именно это я и мечтаю увидеть.
Заинтриговали! Но пока не показали.
Я говорю об источнике. Когда эта этапность будет согласована, документирована и детализирована - да, цитировать могут все, кто имеют доступ к этим проектным документам. Но не ранее.
Возращаемся к началу нашей беседы. Вам по каким-то причинам было проще перериcовать PMBoK и работать с получившимся - нет проблем.
Убедите менеджеров проекта, что это повысит их шансы на успех - и у Вас будет море поклонников. Дело за малым.
Жаль!
Сначала - определения, потом трактовка, разве не так?
Но понимание контекста, границ применимости и друг друга безусловно важно.
Мало ли что называют одними и теми же словами.
Решение менеджера. Все получилось - отлично.
Смотрел и смотрю, история длинная.
Процессы и проекты, если по сути, были всегда, хотя так не назывались. Но можно начать, например, с Тейлора и Файоля.
Как и в Вашем личном примере выше, все действительно важное содержится в постановке задачи и решении менеджера.
Никаких чудес и ничего сакрального в стандарте ISO и литературе на эту тему я не видел. Просто некий формализованный подход со многими вариантами реализации. Завтра придумают новую нотацию, почему нет.
Это просто утверждение - как очередной рецепт коктейля. Доказательства и аргументы не требуются. Важен только вкус и последействие.
Почему любую деятельность? Почему именно в этом суть понимания?
Но если Вы согласны именно с этим подходом - нет проблем. Лишь бы результат Вам понравился.
В быту можно назвать проектом буквально все. Я выше в ветке приводил примеры того, как это слово используют финансисты, политики и др. . Тут мы снова возвращаемся к определениям и решаемой задаче.
Назвать - можно. Оформить - можно попробовать. Если это по сути не проект, то на этом все и закончится. А если действительно проект - отлично, есть шанс его выполнить.
Если для нас важен результат, мы аккуратно пользуемся инструментами и не путаемся с лишними словами. Догматизм и нигилизм нас одинаково не устраивают.
Мы сейчас о процессном или проектном управлении?
Если о проектном, то неопределенность - это норма. Уверен, что все перечисленное можно учесть и правильно документировать.
Боюсь, что не понял вопрос. Олег?
Для проекта уникальность и неопределенность - это объективная реальность, с которыми нужно работать.
Решали не раз - то есть знаете ответ? Делали что-то подобное для другого заказчика? В другое время? В другом месте? С каким бюджетом? Чьими руками? Важны детали.
Много существенных отличий - я бы обсуждал как новый проект.
Покрасить стены другим стандартным цветом - нет, если не доводить факт новизны до абсурда.
На всякий случай спрошу еще раз - мы о проектах?
Использовать - безусловно можно. Были бы проекты.
Что выбираете в качестве методологии - вопрос вторичен и зависит от отрасли и задачи. Это не догма, не шаманство и не гарантия успеха, для меня важнее опыт менеджера проекта и качества исполнителей.
Статистика PM показывает, что основной причиной неуспеха проектов, вплоть до скандалов, является проблемы содержания (Scope). С этим тяжело, но можно бороться - и наоборот.
Увидел, что пара важных слов выпала ... Выделено курсивом.
PDCA может быть в голове у менеджера проекта, помимо прочего, если это ему зачем-то нужно. Формально это не требуется, не таблица умножения.
PDCA для PM можно обсудить отдельно, но с примерами будет легче.
PDCA относится к методологии управления процессами. То есть к управлению циклами. Проект не поддается этой методологии в силу уникальности его исполнения.
Да, согласен. Мы уже 18 страниц об этом говорим, но мнения различаются.
Да я тоже в сомненьях, что правильно понял сказанное. Если вопрос был в ключе п.5) - как действовать в условиях неопределённости в розничных продажах, то спешу успокоить - это везде так, не только в этой отрасли. И уникальность существует обычно до уверенного освоения процессными инструментами, потом почему-то быстро сдувается... )))
Вот с "неопределённостью" нужно бороться, такая фигня в проекте к хорошему не приведёт - проектированием в рамках процесса планирования (да-да, регулярного, в течение всего времени проекта) собственных сценариев действий, лучше нескольких (оптимизм-пессимизм-ровно) и моделированием результатов. Но это ж вроде нормально реализуется любыми стандартами ПУ?
Согласен - если мы все об этом. Должно решаться на уровне процесса продаж.
Для проекта ситуация неопределенности обычная, у менеджера проекта достаточно инструментов. Но к продажам это отношения не имеет, по понятным причинам - ответ выше.
Пока не улоложилось, тут скорее вопрос не в треминологии, а в их нюансировки.
Что такое механика ФУ?
Для меня ФУ - это управление функцией, направлением, подразделением, отделом и т.д. - 1 уровень.
В этом случае - 2 уровень это выбор инструментов управления для решения своих функциональных задач. В этом смысле для процессного и проектного управления есть свой инструментарий.
Если вернутся к предыдущему тезису - широкое понимание процесса, то да, проект это "сложно сочиненный процесс", который обладает наборм конкретных инструментов, которые обязательны для него.
На конкретном примере.
Я выступаю в роли ДРА - производственная компания, производство и продажа спец техники для автотранспорта.
У меня есть/подчиняются 2 подразделения:
а) отдел розничных продаж - работа по входящим запросам,
б) региональный отдел продаж - работа с партнёрами и с дилирами - РФ.
Мне ставится задача увеличить объём продаж, ну вообщем традиционная.
При обсуждении с владельцем я формирую три целевые задачи. (Процесс)
а) розничное направление - повысить % конвертации заказов,
б) региональное направвление РФ - разработать и внедрить "типовой план развиия продаж у партнёров",
в) региональное развитие СНГ - построение системы дистрибуции.
+++
Здесь возникает несколько моментов, причем я не на уровни сущностей или понятий, это довольно конкртная задача
Ситуация очень типичная и вообщем то решается "стандартно". Причём вы будете смеяться во всех случаях, но без использоввания ПУ их невозможно решить эффективно.
Олег, я надеюсь пояснил, почему у меня пока не сложилась картинка, для меня любая теория - это набор конкретных инструментов, принципов, которые можно использовать на практике.
На мой взгляд ни у кого из участников нет желания доказать свою правоту, а то что точки зрения разные - так это наборот здорово.
Если брать ваш бизнес, то использование там ПУ и стандартов это обосновано.
Но вот другой пример, без учета вашей отраслевой специфики, причем тоже конретная ситуация.
Итак, дано производственно коммерческая компания ТНП типа холдинговой структуры. Принято решение создать отдел проектного управления - Проектный офисс.
А) управление этим отделом попадает под понятие процессного управления или нет,
б) управление проектами внутри этого подразделения, на мой взгляд очевидно, что ПУ.
В данном случае речь идет о внутренним, а не о внешнем проектном офисе.
Нет принципиальной разницы, внешний он или внутренний, вся разница, какое юрлицо НДФЛ платить будет ))) ну, и внешникам обычно многое не доверяют, по разным причинам.
По буквам:
А) однозначно процессного, это регулярная деятельность, прекрасно управляемая через PDCA, даже при сильно скачущей мощности реализуемых проектов (процессинг тут как раз поможет вовремя среагировать).
б) Да, в части реализации конкретного проекта (как-бы часть "D" цикла) это сильно (и оправданно) переваливается в сферу стандартов ПУ, но части "Р...СА" пункта А) быстро на практике вам объяснят то, что я тут втолковать пытаюсь )))