Моделирование бизнес-процессов. Управление ИТ-проектами на основе PMBoK

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Компания: IT Premium

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мария Каменнова , генеральный директор,
Андрей Коптелов , директор по ИТ-консалтингу,
"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 и процессно-ориентированного подхода в управлении позволяет решить стратегические вопросы развития ИТ и повысить эффективность регулярной деятельности компании. Это оказывает влияние на развитие бизнеса в целом и обеспечивает быстрый возврат от инвестиций, вложенных в информационные технологии.

Не так часто случается, что гостем нашей традиционной рубрики “Кто он, современный ИТ-руководитель?” становится представитель производителя товаров повседневного спроса. В последний раз это было два года назад, когда мы обсуждали основные задачи ИТ-службы такого предприятия. Сегодня мы продолжаем разговор на эту тему с ИТ-директором компании Efes Rus Василием Власюком, который в беседе с научным редактором PC Week/RE Ольгой Павловой поделился своим опытом руководства ИТ-департаментом регионального подразделения крупной международной компании.

PC Week: Свой нынешний пост вы занимаете недавно — с января текущего года. С какими особенностями в сфере ИТ и бизнеса вам уже пришлось здесь столкнуться?

Василий Власюк: До прихода в Efes Rus я тринадцать лет работал в компании MARS — одном из известнейших производителей кондитерских изделий. И хотя обе компании относятся к одному и тому же рынку потребительских товаров, продукт Efes Rus имеет характерное отличие: он тяжелый и при этом относительно дешевый. Цена грузовика с пивом и грузовика с шоколадом различаются в десятки раз, и потому очень большую роль в затратах играют перевозки. Соответственно в связи с необходимостью оптимизации транспортных потоков у нас более значима роль транспортного менеджмента.

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

PC Week: Наверное, это служит поводом для бизнеса считать ИТ-департамент вспомогательным подразделением, не приносящим никакой прибыли?

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

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

PC Week: А где вы находите ИТ-специалистов, разбирающихся в бизнес-процессах?

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

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

PC Week: Какие первые шаги вы предприняли на новом месте?

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

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

PC Week: Какие вопросы входят в вашу компетенцию как ИТ-директора?

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

Надо сказать, что сегодня Efes Rus переживает непростой период, связанный со слиянием двух компаний (два года назад был создан стратегический альянс британского концерна SABMiller и турецкой Anadolu Efes, в рамках которого компании объединили усилия на рынках России, Турции, а также в странах СНГ, Центральной Азии и Ближнего Востока. — О. П. ). В этой связи передо мной стоит серьёзная задача по объединению разных ИТ-ландшафтов и ИТ-коллективов, выработке единой ИТ-стратегии.

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

PC Week: Что будет представлять собой разрабатываемая вами ИТ-стратегия?

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

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

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

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

PC Week: Помимо закупки мощностей ЦОДов есть ли у вас планы по переводу каких-либо ИТ-сервисов на аутсорсинг?

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

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

Другая проблема использования аутсорсинга связана с тем, что при покупке сервиса требуется тратить время на то, чтобы управлять им, согласовывать уровни предоставления этого сервиса (SLA), следить за тем, чтобы они выполнялись. А если не выполняются, урегулировать разногласия. К сожалению, не получается просто купить и избавиться от забот.

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

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

PC Week: Как вы относитесь к другим популярным сегодня трендам, таким как облачные вычисления, большие данные и прочие?

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

Что же касается больших данных, то если говорить честно, я никогда не сталкивался с этим на практике. Я знаю, что существует направление, позволяющее готовить гибкие отчеты и обладающее другими интересными возможностями, но я ни разу не видел бизнес, который решал бы сегодня какую-нибудь серьезную задачу с применением технологий Big Data. Мне кажется, это всё-таки дело будущего.

PC Week: Легко ли бизнес даёт деньги на внедрение новых технологий?

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

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

PC Week: Какой опыт в последнее время был для вас самым полезным?

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

Главным обстоятельством, повлиявшим на мое решение, стало то, что в MARS имеется очень сильный глобальный ИТ-департамент, который покрывал часть моей ответственности как ИТ-директора в России. С одной стороны, это облегчает работу, а с другой — несколько ограничивало поле для принятия решений. Нередко случалось, что бизнес выдвигает некое требование, глобальные ИТ-руководители не собираются выделять на это деньги, и что я могу поделать? Слишком много времени уходило на проведение бесконечных сложных переговоров. В Efes Rus я имею большую свободу принятия решений, но при этом, конечно же, и большую ответственность. А в результате у нас в ИТ-департаменте самое большое развитие за этот год.

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

PC Week: Спасибо за беседу.

Человек в течение всей истории своего развития старался всячески улучшить условия своего существования. Для этого он, используя свой труд, создавал блага, которые бы обеспечивали его едой, жилищем и другими жизненно важными атрибутами. Тем не менее очевиден факт, что данные новшества со временем морально и физически устаревали, и именно это давало толчок к созданию чего-то кардинально иного. Так, например, создав лук, люди успешно использовали его в военных действиях в течение веков. Однако возросшие потребности военного дела требовали пересмотра существующего арсенала, и так в X веке в Китае появилось первое огнестрельное оружие. Постоянно меняющаяся конъюнктура требовала от человека немедленной реакции в форме изобретения новшеств, что могло бы существенно увеличить его эффективность в тех или иных условиях. С появлением ЭВМ в 50-х годах прошлого столетия мир получил возможность накапливать, обрабатывать и передавать информацию, закодированную в цифровом формате. С развитием технологий, позволяющих таким образом работать с данными, существенно стали увеличиваться объемы информации, которые могли бы быть накоплены, обработаны или переданы. Именно развитие информационных технологий позволяет клиенту банка осуществить перевод денежных средств в дочерний офис на другом конце света за считанные минуты, сотруднику отдела продаж осуществить поиск в массиве данных необходимой информации о клиенте в кратчайшие сроки и банкам, не прибегая к печати банкнот, хранить сотни миллиардов долларов в безналичной форме. Информационные технологии предоставляют возможность экономическим агентам эффективно использовать информацию как фактор производства, увеличив свою производительность. 1.1.Этапы развития общества: от аграрного к информационному Сегодня экспертами принято выделять четыре основных этапа развития общественного порядка: . Аграрное общество; . Индустриальное общество; . Постиндустриальное общество; . Информационное общество; Суть аграрного общества заключается в зависимости от земли как фактора производства, причем первичный сектор является основным для экономической системы данного типа. Таким образом, общественное устройство аграрного типа характеризуется доминирующей ролью сельского хозяйства. До промышленной революции, начавшейся в конце XVIII века, аграрное общество являлось единственной формой общественного строя, что и обуславливало относительно низкие темпы экономического роста в сравнении с двумя последними веками, так как ориентация на ручной труд, отсутствие технологий, сравнительно низкий темп научного развития не позволяли развиваться мировой экономике так стремительно, как это происходит на современном этапе. Низкая социальная дифференциация, являющаяся характерной чертой аграрного общества, подчеркивала сложность самостоятельного накопления больших объемов капитала. Тем не менее, общество, особенное европейское, быстро развивалось. Увеличение объемов торговли, развитие финансовых институтов, науки и факторных рынков способствовали росту спроса на продукцию массового производства, что в результате привело к переходу от ручного труда к машинному типу производства. Данный период характеризуется высоким уровнем экономического роста, урбанизацией, изменениями в общественной структуре и развитием в таких областях как текстильная промышленность, металлургия, транспорт и связь. Индустриальное общество в отличие от аграрного связывают с преобладающей долей вторичного сектора экономики, который включает в себя обрабатывающую промышленность и строительство. Как известно, существует три сектора экономической деятельности: вышеупомянутые первичный и вторичный, представляющие собой сельское хозяйство, добывающую промышленность и обрабатывающую промышленность, строительство соответственно, а также третичный сектор, включающий в себя сферу услуг. На определенном этапе развития общество в состоянии полностью удовлетворить спрос населения на товарную продукцию. Уровень жизн