Понятия «проект» и «процесс» в практике бизнеса оказываются связаны хотя бы потому, что компании, чья деятельность носит ярко выраженный проектный характер, часто вынуждены очень тщательно увязывать «механику» исполнения множества бизнес‑процессов друг с другом. Более того, специфика работы по длительным проектам диктует необходимость детально заниматься не только основными, но и вспомогательными процессами. На конференции AHConferences, посвященной технологиям BPM (Business Process Management) мы встретились с ИТ‑директором Группы компаний «ПИК» Сергеем Потаповым, чтобы обсудить эти вопросы.
Intelligent Enterprise: Тема построения и совершенствования бизнес-процессов затрагивается одной из первых, когда речь заходит о корпоративном управлении. И даже в контексте автоматизации бизнеса она занимает далеко не последнее место. Хотелось бы понять, как осознание ее важности зреет в компании. Даже если учитывать, что ее актуальность признана не сегодня, все равно это понимание на чем‑то должно быть основано.
Сергей Потапов: Я думаю, существует много путей осознания важности понятия бизнес-процесса или совокупности связанных между собой процессов. Но, наверное, все они исходят из попыток совершенствования управленческой деятельности. Даже в докомпьютерную эпоху опытные руководители опирались в своей деятельности на те ориентиры, которые мы сегодня называем ключевыми показателями результативности. В силу отсутствия развитых средств автоматизации это скорее всего были не точные цифры, а более общие характеристики, выражаемые, скажем, в терминах «хорошо — удовлетворительно — плохо». В построении основы для принятия решения они могли смешиваться с субъективными факторами, учет которых диктовался опытом. Но некая агрегация управленческих данных так или иначе присутствовала.
Сегодня, говоря о KPI или BSC, мы просто выводим годами сложившуюся методологию на новый уровень. Благодаря ИТ появилась возможность даже существенно агрегированную информацию представлять в виде весьма точных и при этом разнообразных значений, которые при этом уже можно часто обновлять и связывать между собой.
Чтобы корректно собрать всю базовую информацию и превратить управление по KPI в реальную основу для корпоративного управления, необходимо было сформировать соответствующие условия. Менеджмент предприятия должен однозначно трактовать ту или иную информацию и готовить ее в соответствии с алгоритмами, заранее увязанными между собой. И тут мы неизбежно приходим к необходимости выстраивания четких бизнес-процессов. Внедрение ERP, а также иных управленческих систем тоже является мощным стимулом для того, чтобы начать уделять более пристальное внимание бизнес-процессам, Этот тезис, наверное, уже можно считать банальным. Стоит только отметить, что в данном случае мы уже вынуждены захватывать значительно более широкий спектр бизнес-процессов, которые ранее могли не только не описывать, но даже, по сути, никак не выделять.
Если работа по совершенствованию бизнес-процессов и их автоматизации действительно ведется широким фронтом и разговор начинает идти не только о тех схемах их оптимизации, которые фактически лежат на поверхности, возникает один любопытный момент. Зачастую ситуация с основными процессами быстро проясняется. Бывает даже так, что как раз их нельзя существенно оптимизировать за счет использования информационных технологий. Но одновременно появляется возможность заметно оторваться от конкурентов за счет оптимизации неосновных процессов, направленных, скажем, на улучшение отношений с клиентами. Не трансформируется ли в данном случае само понятие «основной бизнес-процесс»?
Нет, я думаю, основные процессы продолжают оставаться прежними, если только компания радикально не меняет направление своей активности на рынке. И именно на основные бизнес-процессы, напрямую связанные с той деятельностью, с помощью которой коммерческая компания зарабатывает деньги, направлено основное внимание руководства. Другое дело, что с ростом зрелости подходов к управлению руководители начинают все более пристально смотреть на более широкий круг проблем и, что очень существенно, смотреть на все подконтрольное менеджменту пространство бизнес-процессов как на единое целое с множеством внутренних взаимосвязей. Все это, кстати, становится возможным именно благодаря технологиям автоматизации бизнеса.
Приведу в качестве примера деятельность нашей компании. Для простоты и наглядности несколько упрощая ситуацию, скажем, что в нашей компании существует два ключевых бизнес-процесса. Мы — девелоперская компания. Соответственно один из этих процессов подразумевает непосредственно девелопмент, а именно все, начиная от поиска площадок под строительство, определение, что и какими силами там строить, и весь процесс возведения на такой площадке жилого объекта, например, многоквартирного дома определенной серии. Еще один ключевой для нас процесс — продажа квартир, гаражей и всего остального, что мы построили.
В последнее время руководство сделало существенный акцент на автоматизацию основных (ключевых) бизнес-процессов. Девелопмент, как известно, носит сильно выраженный проектный характер, поэтому в качестве инструмента ИТ-поддержки данного бизнес-процесса мы выбрали систему Primavera (эта система относится к классу систем управления проектами). Внедрение этой системы практически завершено. А для автоматизации другого ключевого бизнес-процесса — процесса продаж — мы приняли решение и в настоящий момент внедряем систему класса CRM.
Бизнес ожидает серьезных эффектов от этих внедрений. С позиций девелопмента — это полная прозрачность и контроль за ходом строительства от начала до конца, в результате чего должны сократиться сроки и уменьшиться издержки, связанные с этой деятельностью. С точки зрения продаж речь идет об увеличении доходной части и о росте эффективности продаж нашего продукта большему количеству потенциальных клиентов. Еще раз повторю: это основные процессы, на которые направлено основное внимание руководства.
Но при более детальном подходе к оптимизации (и в условиях автоматизации особенно) вместе с основными процессами на поверхность поднимаются целые пласты сопряженных с ними вспомогательных процессов, на которые также приходится обращать серьезное внимание. Одним из таковых в нашей практике является процесс принятия решения. Иными словами, в рамках внедрения системы Primavera мы поняли, что недостаточно прописывать, скажем, работу проектной команды и обязанности руководителя конкретного инвестиционного проекта. Важное условие — решения, которые принимаются в рамках проекта, должны выполняться. Поскольку проекты у нас сложные и делаются далеко не за один месяц, процесс контроля исполнения принятых решений вырастает в самостоятельную и весьма серьезную задачу. А отсюда уже следует важность решения отдельных подзадач. Нужно, например, чтобы совещания, проводимые в контексте ведения отдельного проекта, протоколировались, а решения из протокола ставились на контроль. Тогда мы поняли, что нам необходима система контроля поручений. В настоящий момент внедрение такой системы завершено. Она успешно используется во всей компании, а не только в той ее части, которая занимается девелоперской деятельностью. И это понятно, ведь процессы в компании взаимосвязаны и контроль поручений должен быть везде.
Данная система, в свою очередь, может стать составной частью корпоративного документооборота, который пронизывает все процессы, включая основные. Дело в том, что различные подразделения компании, исполняя основные бизнес-процессы, порождают множество документов, среди которых большую часть составляют договоры — подряда, купли-продажи и т. д. Если мы действительно занимаемся оптимизацией основных бизнес-процессов, сразу встает вопрос об организации жизненного цикла этих документов: как они рождаются, как утверждаются, где хранятся, как быстро происходит их поиск. Подчеркну еще раз, что в данном случае документооборот является как бы второстепенным процессом. Но если навести тут порядок, то качество исполнения основных процессов может улучшиться буквально в разы. Да и скорость их выполнения возрастет.
Работы по оптимизации и автоматизации бизнес-процессов идут от простого к сложному, от основного к второстепенному, уходя все больше и больше в детали. Бизнес-процессов, которым необходимо уделять пристальное внимание, становится больше. Вообще, при всей очевидности, деление на основные и вспомогательные бизнес-процессы в компании относительно и условно. Ведь часто без отлаженного вспомогательного процесса основной процесс становится либо неэффективным, либо вообще невозможным. Каждый бизнес-процесс должен быть проанализирован, выявлены его взаимосвязи, подобрано решение по автоматизации и т. д. И вслед за ключевыми бизнес-процессами акценты и фокус внимания ИТ-директора неизбежно будут переноситься в сторону всего многообразия взаимосвязанных вспомогательных процессов.
Совершенствование бизнес-процессов ставит на передний план организационный аспект построения этих изменений. Дело в том, что данному виду деятельности часто пытаются поставить в соответствие целые подразделения бизнес-процессов с аналитиками в штате. При этом структура формирования подобных подразделений, их формальная подчиненность — до сих пор в значительной мере дискуссионные темы. Что бы вы могли сказать по этому поводу?
Прежде чем отвечать на этот вопрос, отмечу, что в любой компании люди делятся на две категории. С одной стороны, это те, кого сейчас принято называть визионерами, видящими будущее место компании на рынке, ее бизнес и сам рынок в некой перспективе. Это стратеги по призванию. С другой стороны, есть сотрудники с очень конкретным мышлением, которые хорошо умеют классифицировать объекты, раскладывать их на компоненты, выстраивать последовательности и определять взаимосвязи, но в очень узком профессиональном контексте. И таким людям часто не хватает общего более широкого взгляда, от них могут ускользать более глобальные взаимосвязи между разными частями бизнеса. Ради полноты картины надо сказать, что есть категория людей, которым удается и то и другое, но речь сейчас не о них.
Представленная мною классификация не эквивалентна делению на начальников и подчиненных, но на практике очень часто бывает, что руководители (визионеры) действительно ставят задачу специалистам — своим подчиненным, а те в свою очередь занимаются разработками, пытаясь найти наилучшее решение для конкретной ситуации в рамках конкретного подразделения.
Что все это означает в практике бизнеса? Это означает, что вокруг того или иного руководителя и, как правило, в его департаменте начинают формироваться команды бизнес-аналитиков, пытающихся воплотить ту или иную идею в жизнь, подготовить описание бизнес-процессов, выпустить регламенты, касающиеся ответственности данного департамента. Они и оказываются теми самыми проектировщиками бизнес-процессов, но на своем «локальном» функциональном направлении. Если же посмотреть на компанию в целом, то зачастую нет никого, кто бы отвечал за эффективное построение взаимодействия между подразделениями, между блоками подразделений, кто проектировал бы «кросс-функциональные» бизнес-процессы и отвечал за их эффективность.
Таким проектированием, безусловно, занимается проектная команда на стадии внедрения, например, информационных систем класса ERP. Но по окончании внедрения уже, как правило, не предусматривается какого‑то единого центра управления бизнес-процессами. Все остается на уровне функциональной ответственности, где каждый отвечает только за то, что он делает. Конечно, есть подразделения, которые отвечают за документооборот, в том числе за процесс подготовки, согласования и утверждения различных регламентов и другой нормативно-распорядительной документации. Туда же входит и создание регламентов бизнес-процессов. Но, как правило, эти подразделения лишь фиксируют регламенты бизнес-процессов, не принимая участия в их разработке и тем более в кросс-функциональной увязке и последующем контроле. И как только бизнес-процесс претерпевает изменения, вносимые жизнью, то и регламенты устаревают.
Кто бы мог отвечать в компании за управление эффективностью бизнес-процессов, в особенности кросс-функциональных бизнес-процессов на уровне компании в целом? Это совершенно точно должны быть люди: а) хорошо знающие разные стороны бизнеса компании, б) имеющие авторитет и статус (положение), занимающие высокую позицию, наделенную полномочиями. Другими словами, это должны быть люди из C-клуба. В английском языке (языке международного бизнеса) существуют аббревиатуры руководителей, начинающиеся на букву «c», — CEO, CFO, COO, CIO, CTO. Руководители, которым наиболее близка тема операционной эффективности, — это COO и CIO. Эта тема близка CIO, так как он отвечает за автоматизацию бизнес-процессов по всей компании. Автоматизация и повышение эффективности бизнес-процессов становятся неразрывно связаны друг с другом. И действительно, в высокотехнологичных компаниях CIO все чаще и чаще оказываются ответственными за повышение общей операционной эффективности компании. Но в среднем по рынку CIO в силу разных (скорей исторических) причин все же не хватает авторитета и статуса, чтобы производить серьезные изменения в бизнес-процессах и за это отвечать. CIO, скорее всего, отвечает только за автоматизацию.
С другой стороны, COO часто не хватает компетентности в информационных технологиях и знания того, каким образом ИТ может повлиять на эффективность тех или иных бизнес-процессов. Он может чего‑то не знать и поэтому не обратиться в нужный момент к CIO. А CIO соответственно, не имея запроса от COO, считает, что все в порядке.
На мой взгляд, есть очевидная тенденция объединять эти две роли, две позиции под одной «c». В западных компаниях появляется новая роль под названием Chief Process and Innovation Officer (CPIO) — главный директор по процессам и инновациям. Как мы видим, с одной стороны, добавилась ответственность за процессы, с другой стороны, появилось слово инновация. Инновации, если упростить, означают получение эффекта от внедрения технологий на практике. И действительно, технологии ведь ничего практически не значат до тех пор, пока они в эту практику не воплощены. И технологии при этом невозможно внедрить без понимания, как изменятся соответствующие бизнес-процессы. Многие проблемы в применении технологий вызваны как раз пропастью между людьми, отвечающими за технологии, и людьми, отвечающими за процессы. Если спросить, кто из существующих руководителей наиболее подходит к выполнению новой роли, то, на мой взгляд, это в равной мере могут быть как CIO, так и COO. Все зависит от индивидуальной профессиональной подготовки и личных качеств данных руководителей.
Как известно, ИТ-подразделение компании, и особенно крупной, строит свою работу и организует взаимодействие с бизнесом также на основе процессных методологий. Может ли оно как‑то помочь бизнесу решать задачи построения процессной модели управления?
Я думаю, здесь нет прямой связи. Двигать бизнес в этом направлении можно, но это не входит в число непосредственных задач ИТ-подразделения. Хотя косвенная связь, безусловно, присутствует. Если компания крупная и ее руководство серьезно относится к автоматизации, то целенаправленно строить отношения между ИТ и бизнесом, конечно, приходится. Методологией для такого целенаправленного построения отношений между ИТ и бизнесом может быть методология ITSM, которая во многом как раз и есть методология процессного управления. Ведь все популярные составные части модели ITSM, будь то управление инцидентами, проблемами, конфигурациями, являются ничем иным, как набором взаимосвязанных процессов.
Может даже получиться так, что ИТ‑служба в области культуры процессного управления оказывается впереди бизнеса, которому в тот или иной момент развития эта модель также может стать интересна. Но даже в этой ситуации сложно говорить о прямом заимствовании бизнесом опыта ИТ-подразделения. Другое дело, что департамент ИТ может быть для бизнеса своего рода ориентиром в использовании неких практик. Я думаю, нечто подобное происходит и в нашей компании.
ИТ‑департамент в роли законодателя моды
Сергей Макарьин,
HP ES Sales ExecutiveИз опыта работы могу сделать вывод, что часто ИТ‑департамент становится законодателем мод и примером для других отделов и руководства компаний в целом, как источник компетенции о бизнес-процессах компании. В ИТ-отделе уже знают на практике, как эти процессы можно описывать, трансформировать и связывать. Дискуссии с представителями компаний из разных отраслей только подтверждают данную мысль. И это в целом логично, ведь в большинстве случаев аналитики компаний либо находятся в ИТ-отделах, либо работают в очень тесной связке с ИТ.
Именно ИТ автоматизируют и поддерживают работу абсолютно всех подразделений компаний, независимо от того, основной или поддерживающий это бизнес-процесс. Именно в ИТ-отрасли знание и формализация бизнес-процессов критичны для выполнения основной деятельности (автоматизация). Отсюда и логичное следствие — процессное управление и знание процессов организации как таковой в большинстве случаев сосредоточено в ИТ. И автоматизация процессов управления в ИТ, помноженная на знание процессов организации, приводит ИТ‑департаменты к роли примера или инициатора внедрения более формализованных процессов в других департаментах, включая и основные, и поддерживающие.
В конце концов, основные процессы управления примерно одинаковы для всех направлений с небольшими специфичными акцентами. Особенно ясно это видно, когда речь идет о больших, но относительно молодых бизнесах (холдингах, группах компаний), которые в последние годы отходят от модели экспансии за счет поглощений и приступают к большей формализации бизнеса, к построению вертикально интегрированных компаний. При этой модификации от «набора феодальных царств» к «вертикали управления» опыт ИТ-отдела в выстраивании и формализации процессов особенно востребован. Как я понимаю, в большинстве случаев, создавая вертикальные компании, выстраивание процессов начинают в ИТ, как пилотной зоне, либо прямо используют уже существующие наработки ИТ-отдела и стараются реплицировать описанные и проверенные процессы на другие вертикали бизнеса. Не зря все чаще вместо термина «ITSM» говорят просто о Service Management. И такие проекты, когда выстраивают процессы, начав с ИТ‑департамента и переходя на втором этапе в другие департаменты, сейчас уже широко распространены.
