1. Статьи
Заметки пользователей
16.06.2015 11:20
PDF
14883
136

Задачи, процессы, проекты

О чем и почему

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

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

Задачи

Задача, как задание

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

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

Простые и сложные

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

Регулярные задачи, устранение аварий, создание нового

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

Исходные данные и результаты выполнения

Для выполнения каждой задачи необходимы какие-то исходные данные, то есть, фактически, постановка задачи.

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

Любая задача минимально может быть выполнена или провалена. Нередко вариантов результатов завершения задачи больше.

Процессы

Бизнес-процесс

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

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

  • документирован;
  • принят всеми участниками бизнес-процесса.


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

Документированный бизнес-процесс - это регламент, или procedure, что иногда переводят как "процедура".

Применимость

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

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

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

Регламент

Написание регламента - вопрос совсем непростой, и, нередко, имеет серьезную политическую составляющую.

Я не готов погружаться в вопрос написания регламента слишком глубоко, но несколько важных, по моему мнению, технических моментов, хочу отметить:

  • В документе должна быть вводная часть, в которой указано, где и как этот регламент применим, какие стороны задействованы, каковы стартовые условия, и какие ожидаются варианты исходов.
  • Моделировать процесс можно в разных схемах, каждая компания вправе определять свои правила. Лично мне кажется, что BPMN - один из самых универсальных, и его "умеет" даже Visio.
  • Регламент не подразумевает обязательно линейную последовательность задач. Ветвление по результатам завершения какой-либо задачи вполне нормально, также, как и возврат на какие-то задачи повторно. Обычно используется иерархия задач, когда сложная задача не расписывается, а моделируется отдельно. При этом, каждый уровень модели должен быть достаточно прост и читаем!
  • И ещё раз про ветвление: надо соблюдать разумность в количестве вариантов! Не надо включать в регламент ВСЕ возможные варианты, редкие версии можно оставить на внепроцессную обработку. Если же иначе никак – возможно, следует задачу декомпозировать или пересмотреть весь процесс.
  • Уровень декомпозиции должен быть разумным. Я предлагаю при декомпозиции сложных задач на простые, остановиться на том уровне, когда задачу может полностью выполнить один участник процесса самостоятельно. Даже, если такая задача довольно объемна, она может быть, или документирована внутри подразделения - участника основного бизнес-процесса, или быть документирована инструкцией. Нет смысла вводить в детали внутренних процессов подразделения, всех участников бизнес-процесса.
  • Бизнес-процессы пишутся не для роботов, а для людей, которые могут ошибаться. И делают это! Если потенциальная ошибка в выполнении каждой простой задачи может остаться незамеченной на последующих этапах, и может быть критична для бизнеса, необходимо включить задачу проверки! Тут появляется большая тема оценки рисков, большая и сложная, которую опустим.

Оценка результата и оценка бизнес-процесса

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

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

А вот автор процесса оцениваться по тому, насколько процесс приводит к ожидаемым результатам.

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

В целом, оценить бизнес-процесс так же непросто, как и разработать.

Пример

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

Проекты

Проект

Проект, по ВиКи — "это работы, планы, мероприятия и другие задачи, направленные на создание уникального продукта".

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

Управление проектом

Для того, чтобы проекты могли как-то двигаться, их должен кто-то двигать, или управлять ходом проекта. И этот человек – руководитель или менеджер проекта.

К сожалению, этот термин сильно замылен в современной российской действительности, и роль руководителя проекта нередко сводится к некоторой работе по составлению бессмысленной бумажной отчетности, не имеющей отношение к реальности. Это неправильно. Я под руководителем проекта буду иметь в виду того, кто занимается реальным движением проекта, и заинтересован в его успешном завершении.

Собственно, проектное управление - это целая группа бизнес-процессов. Управление проектами может быть построено на базе известных шаблонов, типа PMBOK, P или PRINCE , а могут быть использованы и собственные.

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

Если в компании нет бизнес-процессов управления проектами, то в компании нет проектов в их настоящем смысле.

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

Задачи проекта

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

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

Конечно, тут нет речи о документировании регламента выполнения проекта, тем более о его согласовании. Тем не менее, многие задачи проекта могут использовать существующие бизнес-процессы компании. Иногда имеет смысл регламентировать какие-то повторяющиеся задачи проекта.

Общую сборку задач выполняет руководитель проекта, и она фактически уникальна для каждого проекта. По ходу проекта задачи обычно отображают в виде диаграммы Ганта, которая достаточно неплохо отражает зависимость задач и показывает сроки проекта, и что на них влияет.

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

Оценка рисков

Оценка рисков – важная часть проектного управления.

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

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

Аварии

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

Тему эту я тоже опущу.

Прочие задачи

Что делать с задачами, для которых не имеет смысла писать бизнес-процесс или затевать проект?

Если нет проблем с их выполнением, то ничего не делать. Оставить их внесистемными, не беспокоиться и продолжать жить счастливо!

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

Если компания будет расти дальше, такие наработки окажутся востребованными.

Заключение

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

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

В этом случае внедрение процессов, и управление проектами, как один из важных процессов, может помочь. При этом надо понимать, что нет "философского камня". Процессы и проекты – инструмент, со своими плюсами и минусами.

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

По моему наблюдению, даже вполне себе большие компании для управления проектами обходятся Excel файлами и диаграммами Ганта (например, в MS Project). Руководитель проекта может контролировать выполнение задач в любой системе работы с задачами, но их последовательность и зависимость между задачами – личное творчество и ответственность руководителя проекта, которому для этого не обязательно нужна сложная система.

Отмазка

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

Я не претендую на Истину, и я допускаю, что, в дальнейшем, получив новый опыт и знания, изменю свою точку зрения на противоположную.

 

Спасибо за уделенное на прочтение текста время.
Связаться с автором можно по email s.kuksa@inbox.ru

136 комментариев
Оставлять комментарии могут только авторизованные пользователи
Robot_NagNews
Robot_NagNews

Материал:

Эта статья появилась, как результат размышлений над темой форума по проектному управлению, после столкновения с терминологическим и понятийным барьером в дискуссии. Нельзя полноценно вести дискуссию, если говорить на разных языках. Статья Алексея Павлюца, упомянутая в обсуждении, безусловно, очень познавательна, но и она не смогла помочь найти взаимопонимания. В попытке объяснить самому себе суть терминов, я пришел к некой модели, которую и описываю тут, как свое понимание терминов.

 

Полный текст

SergoINFOLAN
SergoINFOLAN

;)

Saab95
Saab95

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

Sergey Gilfanov
Sergey Gilfanov

Именно так и пишутся все инструкции в крупных организациях.

До тех пор, пока сотрудникам не приходит в голову их выполнять.

Прохожий
Прохожий

Мило.

Sergey Gilfanov
Sergey Gilfanov

А теперь сравним с совсем-совсем недавней статьей упоминаемого мной когда-то Алиева. Ну очень синхронно прибежало.

Прохожий
Прохожий

А теперь сравним с совсем-совсем недавней статьей упоминаемого мной когда-то Алиева. Ну очень синхронно прибежало.

Там в комментах ему нормально так отсыпали. Самое шедевральное:

 

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

 

И вот точнее не скажешь.

 

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

SergeiK
SergeiK

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

Увы, да, заметно большо 140 символов, не все могут осилить. Но не всем и предназначено!

 

Мило.

Не понятно... Плохо? Хорошо?, Смешно? Глупо?

 

А теперь сравним с совсем-совсем недавней статьей упоминаемого мной когда-то Алиева. Ну очень синхронно прибежало.

Лично я не понял контекста, в котором живет автор.

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

Но процессы - инструмент, который должен быть применим в нужном месте и нужным образом!

Вот, собственно, комментарий там, с которым я согласен:

 

Именно так и пишутся все инструкции в крупных организациях.

До тех пор, пока сотрудникам не приходит в голову их выполнять.

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

К счастью для небольших операторов, у больших операторов такое встречается крайне редко.

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

Kirya
Kirya

А теперь сравним с совсем-совсем недавней статьей упоминаемого мной когда-то Алиева. Ну очень синхронно прибежало.

Кризис в стране.

Много людей сейчас наконец начали осозновать, что занимались они скажем прямо фигней...

Вот и пошли оптимизации в компаниях.

NN----NN
NN----NN

Чёрт побери, чувствую себя гением на фоне всех этих интеллектуальных экзерцисов, ибо при запуске компании с "0" сразу озадачился проектированием структуры (не самая сложная задача для телекома), написанием должностных инструкций, описанием процессов с указанием точек взаимодействия с другими внутри компании и того, чем каждый процесс заканчивается. При этом руководители подразделений должны были решать те нестандартные ситуации, которые не были внесены в описания процессов. Здравый смысл подсказывал, что без всего этого организовать работу и взаимодействие нескольких десятков людей невозможно.