Process, Project, Case и Product management – в чем разница?

Есть много разных видов менеджмента. Наиболее известны process и project management, по которым есть хорошо проработанные учебники и тренинги. Менее известен case management, сравнительно недавно появился product management – управление продуктами, а сейчас как отдельный вид оформляется управление созданием платформ. В статье мы поговорим о том, в чем между ними принципиальная разница, почему это именно отдельные виды, а не варианты одного и того же.

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

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

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

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

Начну я с управления процессами, которое появилось самым первым, с индустриальной революцией, связан с именами Тейлора, Ганта и Форда. А может быть даже раньше, с первых фабрик Аркрайта. Процесс подразумевает, что за счет повторяемых действий у вас получался гарантированный результат. А управление заключается в постоянном мониторинге, выявлении сбойных мест, которые не позволяют этот результат получить, совершенствовании процесса или его перенастройке, если требования к результату меняются. Управлению процессами уже более двух веков, если отсчитывать с первых фабрик. И, естественно наработано много конкретных методов и практик эффективной организации процессов и их изменения. Мы не будем в него углубляться – по нему много книг, курсов и учебников.

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

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

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

Когда так поступили с ипотечными кредитами в массовом порядке, получился мировой кризис 2008 года. Потом вскрылось, что там была схема, побуждавшая выдающих кредит массово увеличивать категорию надежности, и это не было риском исполнителя и, более того, не было риском банка, выдающего кредит, а перекладывалось на третьих лиц. В этом случае для организации оценки рисков, естественно, можно использовать process management – процесс должен гарантировать не возврат кредита, и лишь то, что в случае проблем и проверок регулятором банк окажется чистым, все действовали по инструкции, куда надлежащее количество рисков было заложено. А вот если вас действительно интересует оценка качества кредита, то process management не сработает.

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

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

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

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

Еще один урок связан с автоматизацией компаний. Поскольку организация процессов носит регулярный характер и хорошо проработана, то она хорошо отражается в информационных системах. Разработан даже класс продуктов, BPM-движки, которые хорошо поддерживают процессы и они часто используются как основа. А вот особые случаи и уникальные процессы, кейс менеджмент в них поддерживаются плохо, для него нет стандартных средств. А когда ее пытаются реализовать на BPM-средствах, то оно работает плохо. При ответственном отношении персонала поверх автоматизации возникают неформальные процессы. А чаще сотрудники просто принимают то качество, которое могут дать процессы, как должное. Особенно, если BPM-система считает их KPI. Ну а что в результате больные не выздоравливают, а кредиты – не возвращаются, то это проблемы организации, а не их. И это, в целом, справедливо, ведь именно их руководство решило организовать работу не адекватным образом. Не стоит так делать.

О способах автоматизации, которая бы поддерживала не только процессы, но и работу с уникальными кейсами, я несколько лет назад делал доклад «Process & Case Management в информационной системе: от автоматизации As Is к поддержке развития бизнеса», по ссылке доступна презентация и видео.

Теперь перейдем к управлению проектами. Project management формально появился давно, как метод управления реализацией проектов строительства мостов, крупных зданий и других уникальных сооружений, или освоения месторождений. Уникальных – важно, если у вас строительство нового района, в котором 100 однотипных домов, то это не сто, а один, и много регулярных процессов типового строительства. Уникальность подразумевает, что точно такого проекта не реализовывали ни вы ни другие, или информация об этом вам недоступна, и потому возможны всякие неожиданности, которые следует предусмотреть.

Для этого реализации необходимо провести тщательное проектирование, к которому привлечь опытных компетентных проектировщиков. А также выявить риски, по которым следует вести мониторинг в ходе реализации. Таким образом, всю неопределенность убирают на фазу проектирования, и за счет этого фаза исполнения проекта становится предсказуемой и ведет к результату, а проектный менеджер ситуативно управляет отклонениями в проектном треугольнике объем (scope) – сроки – стоимость.

Однако, когда классический проектный подход попробовали применить для IT-проектов, то он начал давать сбои. Несмотря на тщательное проектирование, результат не получался, или оказывался не нужным. В попытках решить эти проблемы, проектный подход сильно развивался, и современный PMBOK вырос именно из практики ведения IT-проектов. Однако, к успеху это не привело. Почему? Потому что оказалось, что написание кода – это такое низкоуровневое проектирование, со всей присущей НИОКР-фазе неопределенностью и отсутствием гарантий результата. Это было выяснено довольно давно, в 1990-х, и есть классическая статья Джека Ривза (Jack W. Reeves) «What is software design» (1992, перевод) с обоснованием. Впрочем, подобные новости обычно успешно игнорируют.

С тех пор ситуация не улучшилась, а, наоборот, ухудшилась, и это связано с бурным развитием технологий. Для того, чтобы НИОКР приводил к предсказуемым результатам, он должен использовать апробированные технологии. Есть такая шкала – Technology rediness level (TRL), разработанная NASA для оценки технологий, закладываемых при проектировании космических кораблей. Когда Боинг проектирует новый самолет, то разрешается закладывать технологии со зрелостью не ниже 8 из 10, и именно это позволяет Боингу контрактовать самолеты на стадии детального проектирования. Если же мы посмотрим на современную IT-разработку, то там активно используются технологии уровня 4-5. И не из-за тяги к новизне и риску, а потому, что более зрелых технологий, для мобильной разработки просто не успевает появиться – железо развивается очень быстро.

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

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

И именно Agile-методы являются основной современного управления проектами в IT. После примерно десяти лет безуспешных попыток учесть это в очередной версии PMBOK, Project Management Institute (PMI) сдался и начал учить и сертифицировать по Agile-методам.

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

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

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

Кстати, обеспечение востребованности результата, в том числе в изменившихся условиях в классическом проектном управлении находится за рамками проекта. Успешный проект должен лишь реализовать то, что было спроектировано. А использование результата вынесено на уровень программы проектов. Это удобно для подрядчиков – им необходимо лишь выполнить работы, но совершенно неудобно для инвесторов, которых, собственно, результат проекта интересует лишь постольку, поскольку он сможет приносить прибыль. Об этой проблеме у меня в журнале «Управление проектами» была статья «Проекты — для достижения результата, а не для освоения бюджета».

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

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

Product management вырос с появлением public web и массовым созданием продуктов, ориентированных на конечного потребителя. Классическое разделение труда при такой разработке выглядит так: есть люди, отвечающие за идею и видение продукта, и они ставят задачу команде разработчиков, которые реализуют требуемое. То есть они выступают в роли заказчика для обычной разработки. Которая ведется с помощью современного проектного управления, то есть agile-методами.

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

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

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

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

Поэтому в продуктовой разработке все это внесено в общий контур управления. И задачей, например, может быть повышение доли рынка продукта в Латинской Америке с 5 до 8 процентов, потому что это соразмерно доле рынка в других регионах, или потому есть гипотеза, что в продукте чего-то не хватает. Или охват юристов как пользователей, потому что представляется, что у них тоже есть задачи, для которых наш продукт может оказаться полезным. Какие для этого нужно разработать фичи, или провести маркетинговые компании – уже находится внутри этой большой задачи. Мы должны провести исследования, выдвинуть какие-то гипотезы о новых фичах, их реализовать, включить в боевую версию продукта, провести маркетинг. А затем – оценить результат, через A/B-тестирование и статистику использования, чтобы отделить эффект этой гипотезы от других – большие продукты развиваются параллельно по многим направлениям. И далее оценить завершение как успешное, или принять решение о новом эксперименте, сейчас или позднее, или о прекращении движения в этом направлении.

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

Интересно, что примерно такой подход к проверке потенциальных технических решений объясняет успех google glass по сравнению с другими аналогичными проектами, которых вело много компаний, часть из которых начало проекты раньше. Google начинал с изготовления пластилина и других подручных материалов макета в натуральную величину с нужным весом, и проверял, можно ли будет носить это на голове. И только те идеи, которые проходили эту проверку, шли в дальнейшую разработку. А конкуренты начинали с того, что разработчики делали функциональные прототипы, не заботясь о размерах и весе, а потом не могли довести их до требуемых габаритов и веса. Изготовление функционального прототипа – дольше и дороже, чем простой макет. Кстати, сейчас, google glass не канул в лету – результаты проекта используются при разработке устройств для производства, в которых рабочим через дополненную реальность выдают инструкции по выполнению операций. Но платформа для таких приложений требовала массового испытания на широком спектре разных людей, ее и обеспечил google glass.

Интересную историю про легкую проверку гипотез в Касперском я слышал на SECR-2014. У Касперского есть бесплатная утилита, которая позволяет проверить компьютер, если вы подозреваете, что вирус прошел через установленную защиту. Возможно, вы ей пользовались. Она помогает людям, а с другой стороны, продвигает сам антивирус Касперского как продукт. Естественно, после того, как вирус найден, у пользователя есть желание его вылечить, и те, кто ведет проект спрашивали разработчиков – а нельзя ли сделать такую возможность? На что разработчики отвечали, что это – очень непросто, потому что когда работают утилита проверки, на компьютере могут быть установлены другие антивирусы, которые могут мешать, могут быть разные другие проблемы. А сколько подписок на антивирус принесет такая функция – непонятно, поэтому большой бюджет на разработку не выделяли.

Что было сделано в этой ситуации? Была сделана кнопка «вылечить однократно», которая на самом деле устанавливала и запускала полный антивирус, не заботясь о его удалении после проверки. Как выяснилось, в большинстве случаев вылечить – получалось. При этом пользователи не удаляли антивирус, а через месяц, когда он предлагал сделать подписку – оформляли ее. Этот кейс хорошо показывает, чем управление продуктами с подобной проверкой гипотез сильно отличается от управления обычной разработкой. Если любопытно углубиться в тему, можно посмотреть доклад.

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

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

Платформы как отдельный способ организации бизнеса были осмыслены с бурным развитием Uber, Amazon, Booking, за которыми последовали Airbnb, Alibaba и многие другие. При этом важно, что стороны, заключающие сделку на платформе – независимы и делают выбор. Интересно, что на букинге или амазоне выбор делает потребитель, а в Яндекс-такси водитель выбирает, будет ли он принимать конкретный заказ или нет, хотя пассажир, увидев, кто принял заказ, обычно тоже может быстро отказаться.

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

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

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

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

Этот взгляд с помощью Business Model Canvas предложил Александра Остервальдер. Основное тут не сам по себе канвас, а тот анализ новых продуктов, который Александр проводит в своей книге, и которые невозможно было объяснить более традиционными способами, ориентированными на ситуации, когда компания лишь предлагает свой продукт потребителям. Поэтому стоит не просто познакомиться с этим канвасом на тренинге и заполнить его для своего продукта, а прочесть книгу с анализом.

На этом я завершаю свою статью. Конечно, тема – необъятная, и потому я прошел ее поверхностно. И совершенно не затронул такие направления, как Lean, Теория ограничений Голдратта и концепцию цепочек создания ценности и управления по целям в вариантах MBO и OKR, которые являются важной частью современного менеджмента. А также не рассматривал подробно разные методы Agile-менеджмента, который является зонтиком для самых разных методов. Впрочем, рассмотрению Agile-методов было посвящено большое количество моих прошлых статей на портале, полное оглавление которых можно увидеть на моем сайте в разделе «Менеджмент цифрового мира». Другие вопросы я рассмотрю в будущих статьях. Продолжение следует…