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