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

Карл Маркс. Капитал. Том 1. Предисловие к первому изданию.

О бизнес-процессах говорят много и часто преимущественно в связи с автоматизацией бизнеса. Использую этот термин и я, в том числе, в своих статьях, посвященных CRM-системам, ERP, работе с BPMN-нотациями, IDEF0 и других инструментов, которые могут понадобиться в работе бизнес-консультанта и внедрении систем автоматизации. При этом в Рунете понятное и развернутое определение термина «бизнес-процесс» я не нашел.

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

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

Определение бизнес-процесса

Итак, в чем же разница между бизнес-процессом и функций или даже просто обычным процессом? В чем разница между этими терминами? Я пришел к следующему выводу:

Бизнес-процесс – это логическая последовательность действий человека (или нескольких человек) в коллективе. Цель описания бизнес-процесса – анализ и регламентация тех или иных действий в коллективе.

Почему я делаю особый упор на людях и коллективе:

Бизнес-процесс всегда происходит с участием человека. Если действия выполняются автоматической системой или программой, это уже не бизнес-, а технологический процесс или спецификация. И тогда в силу вступают несколько иные стандарты, методы описания и особенности реализации.
В бизнес-процессе всегда задействованы несколько людей в явной или неявной форме. Даже если человек работает один (например, писатель), все равно у него есть заказчики (издательские агентства) и потребители (читатели). Также продавец работает не в «вакууме» - у него есть поставщики и покупатели продукции, и все эти люди также задействованы тем или иным образом в бизнес-процессе.

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

Описание бизнес процесса

Также важно дать определение описанию бизнес процесса:

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

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

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

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

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

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

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

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

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

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

Для наглядности описание технологического процесса может выглядеть таким образом:

Берем заготовку A;
Соединяем ее с заготовкой B;
Обрабатываем под параметры C;
Получаем деталь.

Все однозначно и никаких условных «вилок» не предусматривается.

В бизнес-процессе вполне нормальной считается следующая ситуация:

Получаем вводные данные A:
- Если данные соответствуют условию B, переходим на последовательность действий C;
- Если данные соответствуют условию D, выполняем действия E.
Полученный результат передается на выход.

Т.е. уже в алгоритме процесса предусмотрены возможные условия и разные действия, зависящие от исходных или промежуточных данных.

История появления термина

Я не единожды читал информацию о том, что нотации бизнес-процессов IDEF0 появилось чуть ли ни в середине XIX века. Более реалистичные авторы пишут о периоде Второй Мировой войны. Но и они ошибаются.

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

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

На самом деле описание бизнес-процессов и нотации BPMN появились в 70-е годы XX века, когда повсеместно начали использоваться информационные системы. И сам термин, и нотации понадобились изначально именно для разработки информационный систем.

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

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

Первые методологически проработанные нотации бизнес-процессов (а я буду говорить именно о методологически проработанных нотациях, например, IDEF3***) появились у военных в США. Причина очевидна – уже тогда военные в США пользовались автоматизацией с использованием удаленных соединений, т.е. той самой системой, которая позже стала Интернетом. И при таком уровне применения информационных систем потребность в нотациях бизнес-процессов была особенно актуальной.

***По теме методологически проработанных нотаций хочу также сказать пару слов. Почему я привел в качестве примера IDEF3: я еще не видел более проработанной методологически системы описания бизнес-процессов. Даже BPMN 2.0 все еще развивается и дорабатывается. А если вы почитаете англоязычное описание IDEF3 (перевода на русский я пока не видел), то также сумеете оценить по достоинству глубину его проработки.

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

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

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

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

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

Продажи – это самый простой и наглядный пример. Каждый из нас в роли покупателя, а многие, и в роли продавца знакомы с этим процессом. И все мы знаем, что даже один и тот же человек в разных ситуациях (для разных товаров, разных покупателей, в разную погоду и вообще, в зависимости от настроения) будет продавать несколько по-разному. Но если описать и четко регламентировать определенный бизнес-процесс, то независимо от того, «с какой ноги встал утром продавец», процесс продажи будет определенным образом стандартизирован, ограничен определенными рамками, и, в результате, более стабилен.

Зачем моделировать (описывать) бизнес-процессы

Как я уже не единожды писал, я работаю преимущественно с малым и средним бизнесом, где предоставляю широкий комплекс услуг – от выявления проблем и «узких мест» в работе компании до внедрения предложенных мною решений на уровне программных продуктов и систем автоматизации.

Моделирование бизнес-процессов помогает решить сразу две задачи:

Изучение бизнеса. Графическое изображение в виде схем, т.е. моделирование бизнес-процессов позволяет быстрее понять особенности работы компании и выявить возможные «узкие места».
Обеспечение наглядности. Как известно, «одна картинка стоит тысячи слов». А потому схематическое изображение работы компании помогает руководителю и владельцу бизнеса намного быстрее понять суть проблемы и оценить предложенные варианты решения. В работе бизнес-консультанта (кстати, как и специалиста по внедрению программных продуктов) очень важно, чтобы клиент понимал все преимущества решения. Не менее важна и обратная связь – руководитель на схеме сможет увидеть какие-то недочеты еще на этапе обсуждения проекта, и внедрение обойдется без дополнительных сложностей и внесения изменений в проект «на ходу».

И сочетание изучения истории появления термина с моим личным опытом дает следующее определение:

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

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

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

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

Как описывать бизнес-процессы

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

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

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

Собираем участников процесса (сотрудников);
Собираем входящую информацию, необходимую и достаточную для запуска процесса;
Собираем используемые системы. Это может быть учетная система,CRM, электронная почта, таблицы Excel и т.д. Все, что реально используется в работе, необходимо зафиксировать.
Определяем ожидаемый результат – что будет в конце процесса.
Собираем последовательность действий, которые выполняет человек.
Вычленяем условия. В зависимости от разных входящих данных и промежуточных результатов действия могут быть разными.
Описываем всю собранную информацию в графическом виде в удобной нотации (IDEF3, BPMN 2.0 и т.д.).

Правила описания бизнес-процесса

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

Законченность. Бизнес-процесс должен четко отвечать на вопрос, стоящий перед ним. Если мы говорим о процессе продажи определенного товара или услуги, то бизнес-процесс должен полностью описывать действия, необходимые для получения указанного результата, и завершающегося именно таким результатом (с определенными допущениями, о которых я говорил выше).
Лаконичность. Бизнес-процесс должен сочетать в себе достаточность, т.е. описывать все необходимые этапы и действия, при этом быть максимально лаконичным для простоты восприятия. Лично я вывел для себя «правило 15 минут» - если за этот период времени я могу объяснить руководству компании представленный бизнес-процесс, значит, его можно показывать заказчику. Получается быстрее – прекрасно, требует больше времени и слов – надо подумать, что можно сократить и упростить.
Я когда-то лично видел графическое описание бизнес-процесса, выполненное на листе 2 метров длиной (и соответствующей шириной). Его даже просто рассмотреть и понять, куда ведет какая стрелка крайне сложно. А как его пояснять заказчику, я лично не представляю.
Помните, что человек воспринимает зрительно определенный объем информации, ограниченный, в том числе, определенным размером листа или экрана (это связано с особенностями зрения), а также числом элементов (возможности мозга также ограничены). Простой и лаконичный бизнес-процесс заказчик поймет, просто «охватив» схему взглядом. Сложный и перенасыщенный деталями придется изучать не один час просто для того, чтобы понять, что там отображено. Скорей всего, руководитель компании, который не является экспертом в работе отдельных подразделений, а также ограничен по количеству свободного времени, просто не будет изучать столь сложную конструкцию и не поймет сути даже самых выгодных предложений.
Использование общепризнанных нотаций. Не стоит изобретать собственные обозначения и правила. Используйте нотации, которыми пользуются во всем мире. Я видел в книгах некоторых отечественных авторов попытки создания собственной системы обозначений. И, честно говоря, так и не понял, зачем они усложняют жизнь и себе, и своим читателям. Здесь как с языком – вы можете придумать свой особый язык, но понимать его никто, кроме вас, не будет. А если он окажется похож на существующие, то может еще и путаница появиться. Либо вас сочтут безграмотным, так как вы не по правилам известных языков используете пунктуацию, склоняете слова и т.д. Так и с нотациями – есть уже устоявшиеся, известные людям и, что также немаловажно, интуитивно понятные нотации. Они потому и стали популярны, что в процессе их создания и доработок постоянно тестировались на простоту, однозначность и удобство. Если вы будете использовать готовые нотации, вас будут понимать, воспринимать, как эксперта, да и сами правила нотаций уберегут вас от логических ошибок. Я лично рекомендую IDEF3 и BPMN 2.0.
Все участники бизнес-процесса должны быть учтены и прямо указаны. И делать это необходимо без использования сносок с нумерациями, комментариях в объектах Swimm line (специальные сноски) и т.д. Этим нередко «грешат» любители создавать собственные конструкции вместо использования готовых нотаций. Где-то у них названия не помещаются, где-то им кажется, что длинное название в теле бизнес-процесса будет неудобным. В результате либо приходится искать в сносках, о ком именно идет речь, либо создатели таких бизнес-процессов просто забывают указать кого-то из участников.
Понятное потребителю описание. Самое главное – ваш потребитель, тот, кто будет читать эту нотацию, должен быстро и, в идеале, даже без ваших пояснений понимать описание бизнес-процесс.

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

Распространенные мифы и заблуждения

Не «изобретайте велосипед»! Не нужно придумывать свои нотации.

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

Я не рекомендую так поступать. Во-первых, при использовании готовых инструментов вам не потребуется изобретать свои обозначения и стандарты. Все давно придумано до вас. При этом стандартные нотации действительно понятны интуитивно, читаются однозначно, известны многим людям. Во-вторых, в готовых системах (IDEF3, BPMN 2.0 и пр.) имеется проработанная методология и строгие ограничения. Их можно воспринимать как язык программирования и среду для работы с этим языком. Здесь вы просто не сумеете совершить многих ошибок, от этого вас уберегут стандарты синтаксиса и сама среда (ограничения в редакторе, автоматические проверки).

Не путайте описания бизнес-процессы компании и бизнес-процессы IT систем.

Во многих автоматизированных системах, например, 1С или Zoho CRM, существуют собственные сущности с названием «бизнес-процессы». Но к описываемым в этой статье бизнес-процессах эти сущности не имеют никакого отношения. Считайте их «омонимами», т.е. термины вроде звучат одинаково, но в нашем случае это – описание работы компании, а в IT системах – название группы функций и отчетов.

Распространенная ошибка: Бизнес-процесс обязательно приносит ценность (прибыль).

О том, что бизнес-процессы должны приносить прибыль, я слышал даже от известных спикеров. Более того, видел даже “разбор ошибок” при создании бизнес-процесса, в котором очень много внимания уделяется тому, что 70% действий не несут никакой ценности.

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

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

Возможно ли создать идеальный бизнес-процесс - когда следует остановиться?

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

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

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

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

Мария Каменнова , генеральный директор,
Андрей Коптелов , директор по ИТ-консалтингу,
"IDS Scheer/Логика бизнеса"

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

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

Стратегическое управление ИТ-подразделением

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

Каких целей должно достигать ИТ-подразделение?
Как сбалансировать цели бизнеса и цели в области ИТ?
Как оценивать степень достижения целей и определять, насколько эффективно работают специалисты?
По каким параметрам контролировать деятельность ИТ-подразделения?
Какие процессы наиболее критичны с точки зрения их автоматизации?
Какие проекты в области ИТ наиболее приоритетны?

В настоящий момент в большинстве компаний ИТ-стратегия сформирована, однако часто это достаточно формальный документ, который не делает ИТ-стратегию реально работающей и не связывает стратегические установки и оперативную деятельность ИТ-подразделения. Чтобы ИТ-стратегия из формального документа превратилась в эффективный инструмент стратегического управления, предлагается использовать технологию Balanced Scorecard - BSC (система сбалансированных показателей, ССП), которая позволяет довести стратегию до всех сотрудников ИТ-подразделения и сделать так, чтобы ее реализация стала ежедневной задачей каждого.

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

Преимущество внедрения BSC/ССП состоит в том, что ИТ-подразделение получает некую систему координат для организации действий в соответствии со стратегией и возможность последующего ее мониторинга при помощи ключевых показателей результативности - КПР (Key Performance Indicators, KPI).

При построении единой комплексной системы стратегического управления ИТ-подразделением следует учитывать накопленный опыт в области управления ИТ, творчески применяя его к каждой конкретной ситуации. Данный опыт сосредоточен в Библиотеке передового опыта организации ИТ (IT Infrastructure Library, ITIL).

Формирование целей ИТ-подразделения

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

Если в организации уже разработана ИТ-стратегия, она становится основой для построения дерева целей ИТ-подразделения (рис. 1). Например, если основная цель формулируется как "Обеспечить достаточное количество эффективных и безопасных ИТ-сервисов", то далее, при построении дерева целей, происходит выделение подцелей этой целевой установки по принципу "что это значит?":

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

Дерево целей дает четкое и связанное понимание направлений и логики развития ИТ-подразделения.

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

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

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

Стратегическая карта ИТ-директора

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

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

Перспектива "Финансы" показывает ожидания бизнеса от ИТ-подразделения (как деятельность ИТ-подразделения повлияет на финансовое состояние всей организации).

Перспектива "Клиенты" отражает ожидания клиентов ИТ-подразделения (как деятельность ИТ-подразделения должна выглядеть перед его клиентами).

Перспектива "Процессы" формирует требования к внутренним процессам ИТ-подразделения и процессам взаимодействия с другими подразделениями; она определяет стратегическую важность процессов.

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

Рис. 3. Стратегическая карта ИТ-директора.

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

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

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

Взаимосвязь целей и ключевых показателей результативности

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

Как правило, в ИТ-подразделении существует набор собственных количественно измеримых параметров - ключевых показателей результативности; кроме того, большое число ключевых показателей результативности определено в ITIL. Примерами ключевых показателей результативности для ИТ-подразделения могут служить следующие:

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

Однако при всем обилии КПР, которыми могут измеряться цели, необходимо выбирать ограниченное (два-три) их число, а именно те, которые наиболее полно отражают достижение данной цели (рис. 4). Слишком большое число КПР приведет к неоправданному усложнению системы контроля и повышению трудозатрат для расчета КПР без ощутимого повышения качества системы стратегического управления.

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

Например, достижение цели "Обеспечивать оптимальный уровень надежности и доступности ИТ-сервисов" (рис. 5) можно отслеживать с помощью следующих КПР, источником которых выступает информационная система:

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

Достижение данной цели зависит от выполнения проекта по разработке "Плана доступности" и от эффективности следующих процессов: "Управление инцидентами" и "Управление проблемами".

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

В результате внедрения системы стратегического управления с использованием BSC ИТ-подразделение получает следующие преимущества:

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

Совершенствование бизнес-процессов ИТ-подразделения

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

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

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

Описание процессов ИТ-подразделения происходит "сверху вниз": сначала определяются процессы верхнего уровня, т. е. деятельность подразделения описывается "крупными мазками", а далее они детализируются до уровня рабочих мест. Пример процессов верхнего уровня ИТ-подразделения приведен на рис. 6. Для выделения процессов верхнего уровня ИТ-подразделения могут использоваться так называемые референтные модели, а именно ITSM HP Reference Model (Hewlett-Packard), Microsoft Operations Framework (Microsoft), IT Process Model (IBM), ARIS ITIL Reference Model (IDS Scheer).

Основываясь на опыте проектов, можно выделить следующие процессы ИТ-подразделения:

управление ИТ-стратегией;
планирование и бюджетирование;
контроллинг;
предоставление сервисов;
поддержка сервисов;
управление проектами (проектирование и внедрение);
обеспечение информационной безопасности;
управление инфраструктурой;
управление персоналом.

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

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

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

бизнес-прогноз и планирование услуг;
управление ИТ-стратегией;
предоставление сервисов (управление уровнем сервиса; управление финансами);
поддержка сервисов (взаимодействие с пользователями; управление инцидентами; управление проблемами).

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

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

В рамках совершенствования для каждого из рассматриваемых процессов определяют следующие параметры:

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

Разработка процесса должна происходить с активным участием его владельца. Как правило, описание процесса создается в графической форме, что обеспечивает понятность и формализованность всех компонентов (рис. 7). Детальный процесс можно считать разработанным в том случае, если определены все условия его выполнения, участники (бизнес-роли), функции, документы, информационные системы и т. д. При детальном описании процессов возможен анализ и оптимизация их стоимости с помощью метода Activity-based costing (АВС) на этапе совершенствования.

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

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

В то же время, помимо совершенствования процессов, необходимо регламентировать взаимоотношения между бизнесом и ИТ, что достигается разработкой "Соглашения об уровне услуг" (Service Level Agreement, SLA), которое регламентирует предоставляемые услуги в области ИТ и формализует требования к процессам на этапе их создания.

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

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

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

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

Под термином workflow понимается управление потоком работ и через него - бизнес-процессом. Согласно глоссарию международной организации Workflow Management Coalition (WfMC), workflow - это автоматизация, полная или частичная, бизнес-процесса, при которой документы, информация или задания передаются для выполнения необходимых действий от одного участника к другому в соответствии с набором процедурных правил. Автоматизация предполагает наличие набора правил, которые намного сложнее нарушить (умышленно или случайно), чем регламент или должностную инструкцию.

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

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

Вместо заключения

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

Есть одно известное высказывание: «Каждая наука настолько наука, насколько в ней есть математики». Сегодня нечто похожее можно сказать про взаимосвязь бизнес-процессов и информационных технологий. Подавляющее большинство бизнес-процессов эффективны настолько, насколько они обеспечиваются эффективными и оптимальными решениями в плане ИТ.

К этому состоянию бизнес пришел сравнительно недавно. Всего 10-15 лет назад внедрение ИТ-технологий в бизнес проходило через странно звучащие сегодня этапы:

1. «Начальное заражение бизнеса информационными технологиями». Было время, когда ИТ реально воспринималось субъектами бизнес-процессов как игрушка, новая мода, более мощный, но непонятный и сложный калькулятор.
Я помню до сих пор бухгалтеров старой закалки, которые доверяли больше железным арифмометрам, и это было милое время, когда между ИТ-специалистами (поголовно называемыми программистами) и бизнес-подразделениями царила «гармония». Никто друг другу не мешал.
Но потом молодые бухгалтеры (двоечники, не научившиеся в институтах считать на арифмометрах и калькуляторах) стали требовать, чтобы ПК не зависали, чтобы программа считала быстрее, чтобы печать бланков соответствовала ГОСТам, чтобы (о боже!) два сотрудника одновременно могли работать с одной базой.
Айтишники встретили новое время с энтузиазмом, заразившим руководство готовностью утверждать новые штатные расписания и расходы на сервера, СКС, модемы и даже цветные лазерные принтеры стоимостью с новый автомобиль.

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

3. «Управление данными» — этап осознания роли ИТ в бизнесе как основного инструмента по эффективному управлению информацией, информационными потоками.
Данные перестают «обрабатываться с помощью ИТ», данные вместе с операциями над ними (описанными в бизнес-процессах) - образуют информационную систему, а ИТ-инфраструктура обеспечивает эффективную работу в интересах бизнеса инфосистем предприятия.

4. «Зрелость» — тот этап, к которому шли раньше предприятия годами, и который сейчас должен реализовываться в течение нескольких месяцев после начала работы бизнес-единицы, а ещё лучше за несколько месяцев до начала.
Зрелость — это когда все информационные потоки, образующие информационную систему, как раз и являются отражением структуры предприятия и всех её бизнес-процессов.
То есть ИТ перестает быть всего лишь инструментом-палочкой (раньше даже термин был — «костыль»). Роль информационных технологий в бизнесе изменилась. Теперь ИТ и есть бизнес, неотъемлемая его часть, зарабатывающая не деньги на покупку серверов, а вообще ВСЕ деньги для компании.
На этом этапе топ-менеджеры уже не могут «переводить стрелки» на сисадмина (или ИТ-менеджера) при невыполнении задач из-за неработающей электронной почты.
И у ИТ-менеджера метрики и KPI завязаны на результаты всей компании, а не только на uptime серверов. Это этап общей ответственности и понимания, что ИТ (информационные технологии) — это общий термин для бизнес-технологий.

Следующий этап — это когда ИТ порождают новые бизнес-модели за счёт глобального проникновения и всеобъемлющего информационного доступа. Не исключено, что лет через 10 будет совсем неуместным вопрос, есть ли бизнес и бизнес-процессы вне Интернета (или как он тогда будет называться).

Журнал «Корпоративные системы», июль-август 2007г, Киев

Роль IT -подразделения в описании бизнес-процессов компании

Качественное описание бизнес-процессов основывается на графическом моделировании. Это бесспорно информационная технология и прогрессивные IT-подразделения могут и должны внедрять ее в своих компаниях. Сейчас перед IT-подразделениями стоит задача не только оказывать IT-услуги своим компаниям, но и участвовать в достижении бизнес-результатов. Эта идея уже лет 7 активно обсуждается и реализуется западными IT-менеджерами. Они уверены, что IT-специалисты могут не только моделировать бизнес-процессы компании, но и участвовать в их анализе и оптимизации, привнося свое уникальное видение в методы ведения бизнеса. IT и бизнес — одна команда, и чем слаженней они будут работать, тем лучше будут совместные результаты.

Идея и необходимость описания бизнес-процессов

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

Из личного опыта: Когда я работала системным аналитиком в отделе автоматизации крупного холдинга, именно IT директор организовал для топ-менеджеров мини-семинар по рассмотрению деятельности компании через бизнес-процессы (и это было 3 года назад). Так же, он обучал сотрудников своего отдела методикам моделирования бизнес-процессов, инициировал проекты по описанию бизнес-процессов не только для целей автоматизации, но и для реорганизации отдельных компаний и подразделений холдинга. На это его вдохновило обучение на MBA. Фактически, IT-директор выполнял функции руководителя IT-подразделения и CIO холдинга.

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

Подготовка компании к проекту по описанию бизнес-процессов

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

Цель

Возможные цели проекта по описанию бизнес-процессов — это структуризация и регламентация компании, тиражирование бизнеса, оптимизация бизнес-процессов, внедрение СМК ИСО, функционально-стоимостной анализ деятельности компании, проектирование и внедрение ИС и т. д. Однако это очень общие формулировки, чтобы в конце проекта оценить, насколько вы достигли своей цели. Например, если ваша цель описать бизнес-процессы для тиражирования бизнеса, то ее можно детализировать как выделение основных бизнес-процессов компании XXX и разработка процессных регламентов. Для тиражирования бизнеса надо разработать еще ряд документов, но вы ограничили свой проект с помощью цели и можете точно сказать, что когда процессные регламенты выделенных бизнес-процессов разработаны, ваш проект успешно завершен. Процессные регламенты включают в себя графическую модель бизнес-процесса, ее текстовое описание, перечень поставщиков и клиентов бизнес-процесса, входы, выходы и параметры бизнес-процесса и т. д. В своем проекте вы можете ограничиться только разработкой моделей бизнес-процессов, тогда именно это и запишите в цель проекта: выделение бизнес-процессов компании ХХХ и разработка графических моделей.

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

Обучение

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

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

Команда

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

Основной фигурой, которая может не входить в рабочую группу, но должна обязательно быть обозначенной — Заказчик проекта. Это человек, которому нужно описание бизнес-процессов и он обязательно должен иметь соответствующие полномочия и ресурсы для проведения работ. Заказчиком может выступать владелец бизнеса или топ-менеджер (директор, зам. директора, руководитель функционального направления). Даже если бизнес-процессы описываются для постановки задачи к ИС, то Заказчиком этого описания должен выступать топ-менеджер, заказывающий ИС. Зачастую руководители IT-подразделений берут в этой ситуации функции Заказчика на себя, но они не всегда имеют соответствующие полномочия и ресурсы: участники описываемых бизнес-процессов не уделяют достаточно времени на проект, согласование моделей затягивается или вообще не выполняется.

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

Работу по сбору информации, формированию моделей и разработке процессных регламентов выполняют Аналитики проекта. С этой функцией лучше всего справляются IT-специалисты или люди с подобного рода образованием, потому что они владеют Case-средствами (или могут быстро их освоить), а так же имеют опыт разработки алгоритмов и схем. Хорошими Аналитиками становятся и те сотрудники компании, которые в своей деятельности, так или иначе, сталкиваются с анализом или регламентацией деятельности компании — это сотрудники отделов планирования и анализа, менеджеры по качеству и т. д.

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

Секретарь рабочей группы — не очень большая, но ответственная роль. Он организует заседания рабочей группы, фиксирует принимаемые решения и контролирует их исполнения. Фактически он является помощником Руководителя проекта, его левой рукой и «контрольным» органом. В роли секретаря должен быть высокоорганизованный, ответственный, исполнительный человек и некоторые IT-специалисты обладают такими качествами.

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

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

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

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

План

И последний шаг в подготовке проекта по описанию бизнес-процессов — это планирование. Сначала определяется структура работ, исполнители и необходимые трудозатраты. Затем делается календарная привязка и определяется длительность работ: в плане учитываются праздники, дни рождения боса, корпоративные выезды и командировки. К примеру, вам на согласование модели бизнес-процесса надо всего-то 3 часа. С этой целью вы запланировали 2 встречи с Владельцем и Экспертами этого бизнес-процесса с перерывом в два дня. Длительность работ по согласованию модели бизнес-процесса составит 4 дня, но если в этот период Владелец бизнес-процесса уедет в командировку или возьмет несколько отгулов на празднование своего дня рождения, то длительность работ может существенно увеличится. Конечно, помимо запланированных, бывают и «внезапные» командировки, а для этого между работами проекта оставляется временной лаг. Это означает, что если длительность работ по согласованию модели бизнес-процесса составляет 4 дня, то перед началом следующей работы по формирование структуры процессного регламента надо оставить 1 резервный день. (рис.3). Когда такие лаги выставлены по всему проекту, то даже незапланированное отсутствие кого-то из участников проекта не повлияет на суммарную длительность проекта.

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

Бизнес-результаты проекта по описанию процессов компании

«Если раньше IT оценивались исключительно по тому, насколько успешно они осуществляли технологические проекты, то в последующие пять лет они будут оцениваться по тому, насколько сами эти проекты помогают бизнесу в его деятельности». Это было написано в журнале CIO Magazine еще вначале 2000-х. Время оценивать работу IT-подразделений по бизнес-результатам пришло. Проект по описанию бизнес-процессов несомненно поможет бизнесу в его деятельности и будет способствовать:

повышению прозрачности деятельности компании;
закреплению зон ответственности сотрудников компании;
улучшению взаимодействия подразделений;
решению проблемы «незаменимых сотрудников».

И если проект по описанию бизнес-процессов компании инициирует IT-подразделение, то достичь перечисленных результатов оно может только в тесном сотрудничестве и взаимопонимании с бизнесом. По этому поводу хорошее выражение присутствовало в выступлении Эдуарда Савушкина (корпорация Инком) на съезде IT-директоров 2007 г в Киеве: не бывает IT-проектов, бывают бизнес-проекты с вовлечением IT.

Карта бизнес процессов

Компания: IT Premium

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

С кем проводилась работа: Максим Прокопов, CEO и со-учредитель.

Одной из особенностей компании является то, что они не реализуют активные продажи в общепринятом смысле. Обращения новых клиентов построены на рекомендациях текущих клиентов и партнеров компании. Данная особенность накладывает высокий уровень обязательств на работу всех процессов компании – только хорошо отлаженые процессы и постоянное их улучшение, позволяет высококачественно удовлетворять потребности клиентов и, тем самым, повышать уровень репутации на рынке. Молодцы ребята!

Изначальная информация

По итогам первого обсуждения мы с Максимом, подготовили наброски карты, которая приняла следующий вид:

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

Карта основных бизнес процессов компании IT Premium

Карта основных бизнес процессов IT Premium

Как видите, изменения колоссальны. Но что самое важное – мне удалось донести свое видение и методику подготовки карты процессов, до директора компании. Вот что говорит на эту тему сам Максим:

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

В процессе работы с Романом неясные места становились все более ясными, и, в результате “домашней работы” у меня получилось построить карту процессов самостоятельно от начала и до конца!

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

Спасибо за проведенный эксперимент.

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

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

Краткое описание основных процессов

Основные процессы:

Прием заявок – процесс отвечает за прием и обработку всех клиентских заявок, вне зависимости от того, в первый раз обращается клиент или нет. Сначала заявка регистрируется в системе и затем проходит обработку, в результате которой, определяются все необходимые, для выполнения, условия и назначается ответственный. Результатом процесса является, обработанная и назначенная исполнителю, заявка. Если заявка относится к одному из следующих типов:

Заявка на разовое обслуживание
Первичное обращение клиента
Заявка на обслуживание, выходящее за рамки ранее заключенного контракта

То заявка переходит в процесс «Согласование объема услуг и стоимости»

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

Мониторинг ИТ системы заказчика – процесс заключается в регулярном осмотре ИТ системы клиента. Процесс запускается если у заказчика есть такое требование. Может проводится мониторинг как всей системы так и отдельных ее частей, а так же как удаленно так и с помощью выезда специалиста. Условия определяются в процессе «Согласование объема и стоимости». Тем не менее, даже периодическое звонки менеджеров с простым вопросом «Все ли у вас хорошо работает?», являются мониторингом. Такое обслуживание может проводиться не только по требованию клиента но на усмотрение ответственных менеджеров.

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

Вспомогательные процессы:

Коммуникации с клиентом – все контакты с клиентом и все что с этим связано. Данный процесс отвечает на следующие вопросы:

Кто связывается с клиентом?
С кем связывается клиент?
Какие каналы коммуникаций используются?
Какие сообщения доносятся до клиентов?
В какой форме проходят сообщения?
И т.д.

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

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

Персонал – все что касается набора, обучения, мотивации и текущей работы с персоналом компании.

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

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

Коммуникации с поставщиками – данный процесс дублирует цели и задачи процесса «Коммуникации с клиентом», но в отношении поставщиков.

Процессы управления:

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

Управление ресурсами – процесс отвечает за распределение и координацию всех ресурсов компании по процессам. Так же данный процесс отвечает за обеспечение ресурсами внутренних процессов и нужд компании.

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

Управление продуктами – анализ, разработка, реализация и внедрение новых продуктов компании.

Стратегическое планирование и развитие – процесс, результатом которого является стратегия компании. Ее разработка, обеспечение, контроль и т.д. Совместно с процессом «Управление бизнес процессами», отвечает за эффективность и успех компании.

Управление финансами – управление финансовыми потоками.

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

Енвд