Бизнес-аналитика: достижение целей через понимание задач
Емкость понятий «бизнес» и «аналитика», пожалуй, того же порядка, что и таких общих понятий, как «дружба», «работа», «отдых». Поэтому неудивительно то, что под понятие «бизнес-аналитика» подпадает весьма и весьма значительное количество видов деятельности. До настоящего момента я не встречал ни одного определения этого термина, в котором более или менее полно давалась бы его структура, т.е. то из чего, собственно, бизнес-аналитика состоит, чем конкретно занимается бизнес-аналитик и т.п. Еще сложнее обозначить границы бизнес-аналитики, выделить ее среди таких понятий, как «менеджмент», «консалтинг», «информационные технологии».
Вероятно, в силу этих причин в своей работе я регулярно сталкиваюсь либо с недопониманием того, что это такое и для чего это нужно, либо с искаженным понимаем, выделением лишь узкого спектра работ, входящих в это понятие, или же обозначением того, что к бизнес-аналитике явно не относится. Это побудило меня к тому, чтобы написать статью на тему бизнес-аналитики. Как я уже писал выше, пытаться давать определение и всеобъемлющую структуру этого термина – дело, на мой взгляд, малоперспективное. Вместо этого я попытаюсь обрисовать сие понятие с сугубо практической точки зрения с акцентом на то, чем бизнес-аналитика может быть полезна для организаций различных мастей и размеров.
В облаках? Значит все под рукой!
Мы живем в информационную эпоху и, как следствие, для все большего числа людей информация становится основным активом и «материалом» в их повседневной деятельности. Информация, с которой мы работаем, обыкновенно рассредоточена по множеству файлов, приложений, баз данных, мобильных и не очень мобильных устройств в различных точках нашей планеты. Причем, рассредоточена настолько хорошо, что далеко не всегда нам удается удобно и своевременно получить к ней доступ и произвести с ней необходимые действия.
Например, мы создали дома файл, который нам потребовался на работе. Он себе лежит на выключенном домашнем компьютере… Ах да, надо было записать его на флэшку. Нет, все равно не выйдет, программа для его открытия установлена только на том компьютере. Вы ходите на работу с ноутбуком? Тогда с файлом проблемы нет, а вот как быть с доступом к корпоративной базе данных? У вас настроен удаленный доступ к корпоративной сети? Отлично! Да вот беда, ваш провайдер блокирует эти порты из соображений безопасности. Ничего! Сейчас подключимся через мобильник и зайдем на сервер терминалов. Ой, к вам еще не пришел 3G? Как же все тормозит! Да вот еще как назло под рукой только коммуникатор, а срочно нужен этот файл. Вы не выложили его в Sharepoint? У вас дома нет личного вэб-сервера с настроенным доступом к файлам через WebDAV? Вообщем, в это раз вам, похоже, не повезло и к своей информации в самый нужный момент вы доступ не получите, не смотря на то, чтобы для того, чтобы мало-мальски иметь ее под рукой вам приходится использовать все 33 системы.
Виртуализация офиса – думать иначе!
Сколько раз, проводя часы, дни, недели и месяцы, стоя в московских пробках по дороге на работу и с работы я задумывался о том для чего я это делаю… Нет, я не думал о фрилансе, ведь действительно крупные и серьезные проекты под силу только крупным и серьезным компаниям. Я не думал о своем бизнесе и жизни рантье – для этого необходимы значительные инвестиции и стартовый капитал. Я думал о том, почему при современном уровне развития и дешевизне телекоммуникаций мне приходится перемещаться из точки А в точку Б для того, чтобы делать свою работу.
Мой обычный рабочий день как руководителя ИТ-проектов начинается с того, что я достаю из сумки свой ноутбук, подключаю его к корпоративной сети, просматриваю электронную почту и работаю еще с несколькими специализированными информационными системами. Параллельно «сажусь» на телефон и вызванию представителей заказчика и участников проектной команды. И так весь день. Я даже с программистами и аналитиками лично общаюсь не часто, потому что это другой этаж и по большинству оперативных вопросов быстрее все решить по телефону.
ИТ-стратегия, часть 3-я: консалтинг в области стратегического управления ИТ
В предыдущих двух статьях, посвященных ИТ-стратегии, были последовательно рассмотрены общий стратегический процесс в организации и стратегический процесс в области ИТ, являющийся его частью. В этой статье мы остановимся на возможном участии консультанта в разработке ИТ-стратегии. Посмотрим в каких случаях, чем, как и почему человек со стороны может помочь компании в развитии стратегического процесса и достижении целей бизнеса.
Варианты участия консультанта
Вне всякого сомнения все без исключения этапы стратегического процесса в организации могут осуществляться целиком силами собственных ресурсов компании без привлечения внешних специалистов. Однако, в некоторых случаях существует возможность добиться значительно лучшего результата путем привлечения внешнего консультанта по сравнению с формированием ИТ-стратегии только собственными силами.
Целесообразность привлечения консультанта к составлению ИТ-стратегии, как правило, существует в тех же самых случаях, что и для других типов проектов ИТ- и управленческого консалтинга.
Так, обычно консультант привлекается для более эффективного осуществления задач управления в какой-то сфере, например, в сфере ИТ. Соответственно, консультант, как и менеджер внутри компании, призван решать или содействовать решению тех же самых задач управления.
ИТ-стратегия, часть 2-я: определение, границы, содержание, процессы разработки и реализации
Определение и границы ИТ-стратегии
Итак, в предыдущей статье было показано, что стратегия ИТ – часть общей стратегии компании, в которой рассматривается использование ИТ для достижения компанией устойчивого конкурентного преимущества и иных стратегических целей.
Можно выделить «горизонтальные» и «вертикальные» границы понятия «ИТ-стратегия».
Горизонтальные границы ИТ-стратегии определяются границами ИТ как «предметной области» относительно других областей (финансы, производство, управления персоналом и др.), т.к. именно они в данном случае являются объектом рассмотрения ИТ-стратегии.
Согласно одному из существующих определений, ИТ – есть совокупность аппаратного, программного и алгоритмического (интеллектуального) обеспечения, а также сеть поддержки этих компонентов [10].
ИТ-стратегия, часть 1-я: общий стратегический процесс в организации
В этой работе рассматриваются процессы стратегического управления ИТ в коммерческих организациях и ИТ-стратегия, как ключевой, интегрирующий элемент в рамках этих процессов.
В бизнесе многих организаций ИТ используются неэффективно или недостаточно эффективно. Так, по результатам ежегодного исследования «СHAOS Summary 2009» компании The Standish Group Internation, Inc. лишь 32% ИТ-проектов завершились в срок, в рамках выделенного бюджета и с требуемой функциональностью, 44% ИТ-проектов превысили, как минимум один из этих показателей и 24% ИТ-проектов не были завершены вовсе [1].
При этом следует отметить, что в рамках данного исследования в качестве критериев «успешности» использовались достаточно легко измеримые, но вместе с тем не всегда адекватные показатели (сроки, бюджет, функции). В частности, можно предположить, что среди 32% «успешных» проектов, выполненных в срок, в рамках выделенного бюджета и в соответствии с исходными функциональными требованиями, есть проекты, затраты на реализацию которых не привели к ожидавшимся выгодам для бизнеса. В простейшем случае могло оказаться, что сумма издержек, связанных с созданием и дальнейшим владением ИТ-решением оказалась больше, чем сумма дополнительного дохода, обусловленного использованием данного решения в компании. Вряд ли такой проект можно назвать успешным и это не может не беспокоить руководителей и ИТ-директоров компаний.
Очевидно, что причин недостаточно эффективного использования ИТ в организациях существует множество. При этом, по мнению автора, далеко не самое последнее место среди них занимает отсутствие или недостаточное развитие в компании стратегического подхода к управлению ИТ (нехватка целостности, увязки с бизнес-целями, контроля и др.).
В связи с этим, особую важность приобретает максимально возможная в реальных условиях формализация и стандартизация стратегического процесса в области ИТ в контексте общего стратегического процесса.
Системная интеграция: технический аспект
В этой статье будет рассмотрена деятельность под названием «системная интеграция», которой занимаются ИТ-компании, именующие себя «системными интеграторами». Автор несколько лет работал менеджером проектов в одном из российских системных интеграторов, поэтому попытается описать это понятие «изнутри», четко определить его, рассмотреть виды системной интеграции, подходы к ее осуществлению.
Для начала мы опишем термин «системная интеграция», приведем различные определения. Затем рассмотрим его структуру с точки зрения видов работ, выполняемых в рамках системной интеграции: технический аспект, управленческий аспект и др. И, наконец, подробно остановимся на техническом аспекте – опишем виды, технологии системной интеграции, специализированные программные продукты.
Разработка технического задания (ТЗ) на программный продукт с точки зрения заказчика
За время своей работы мне удалось взглянуть на процесс разработки технических заданий на программные продукты с нескольких точек зрения. С точки зрения аналитика – непосредственного исполнителя работ, с точки зрения руководителя проекта со стороны исполнителя, организующего процесс создания ТЗ, с точки зрения руководителя группы разработчиков, реализующих эти самые ТЗ, а также с точки зрения заказчика системы, впоследствии принимающего решение по разработанному ранее ТЗ.
Надо сказать, что у каждой из этих заинтересованных сторон свои требования и свое видение того, каким должно быть «хорошо написанное ТЗ». Например, у заказчика и исполнителя могут быть совершенно противоположные мнения на этот счет. Исполнитель может быть заинтересован в максимально подробном ТЗ для того, чтобы максимально формализовать свои обязательства по функционалу создаваемого решения. При этом заказчик, который точно не определился с параметрами будущей системы или у которого «ветер в голове», может требовать более общих формулировок, описания системы крупными мазками для того, чтобы потом попытаться включить в рамки оговоренного бюджета новые требования. Конечно же, при другом «менталитете» заказчика и исполнителя все может быть с точностью до наоборот. Сейчас мне хотелось бы остановиться именно на разработке ТЗ с точки зрения его заказчика, рассмотрев возможные ситуации, цели и тактики поведения.
Для начала определимся с тем, какие факторы влияют на разработку ТЗ. Прежде всего, это степень понимания заказчиком требований. Как уже говорилось выше, в момент начала работы над ТЗ вы можете слабо себе представлять, какую именно систему вы хотите создать. В качестве исходных данных у вас могут быть разрозненные, часто противоречащие друг другу запросы от подразделений, заинтересованных в создании новой системы. Хорошо, если вашей ИТ-службе удалось структурировать их, разрешить противоречия и, тем самым, подготовиться к общению с подрядчиком. Если же нет, то лучший вариант – это сначала разработать очень общее ТЗ, крупными мазками описывающее видение системы, перечислить необходимые модули (подсистемы), не углубляясь в подробности их функционирования, и далее совместно с исполнителем работать над детализацией требований к ним. Последующие версии ТЗ можно оформлять в виде дополнений к первоначальному ТЗ или в виде т.н. «частных технических заданий» (ЧТЗ) на модули решения. Это даст вам время лучше понять что же вы хотите получить в итоге, мобилизовать на работу над проектом подразделения компании, собрать необходимую информацию, освоить основные понятия, если тематика создаваемого решения для вас нова. Также исполнитель сможет лучше познакомиться с деятельностью вашей компании.
Аналитический аппарат для принятия решений – вероятностные и экспертные методы
Вероятностные методы принятия решений
Большинство решений принимается в условиях недостатка информации и неопределенности. Это связано с тем, что принимаемое решение реализуется в будущем. Соответственно, при принятии решения мы опираемся на некоторое видение (модель) будущего, сценарий развития событий. Однако очевидно, что будущее не может быть спрогнозировано со 100%-ной вероятностью. Более того, часто оно не может быть спрогнозировано и с вероятностью большей 50%. Тем не менее, решения, касающиеся будущего, принимать необходимо.
Для этого может быть использован достаточно простой подход, который заключается в рассмотрении нескольких возможных сценариев развития событий в будущем и результата, к которому приведет каждый альтернативный вариант действий в случае реализации каждого из сценариев будущего. Графически это обычно представляется в виде матрицы, измерениями которой являются варианты будущего и анализируемые варианты действий. После этого по каждому варианту действий рассчитывается некоторый усредненный результат по всем сценариям развития будущего. Затем выбирается вариант действий с оптимальным рассчитанным результатом. Он и является искомым рещением.
Это похоже на игру между двумя участниками, рассмотренную в предыдущем разделе. Однако в данном случае вторым участником выступает не человек, а природа (судьба, проведение и т.п.).
Аналитический аппарат для принятия решений – математическая оптимизация
Линейное программирование
Линейное программирование представляет собой математический метод для принятия решений, заключающийся в поиске оптимального значения целевой функции, зависящей от некоторых переменных, при заданных дополнительных ограничениях. При этом и целевая функция и ограничения должны быть линейны. Существуют математические алгоритмы и программное обеспечение, позволяющее искать оптимум целевой функции при заданных ограничениях. Очевидно, что найденные значения переменных функции, соответствующие ее оптимуму и будут являться искомым решением.
Для примера рассмотрим простую задачу, которую решим графически.
Пусть перед компанией А стоит задача организовать рекламную компанию, длительностью один месяц, на которую выделено в бюджете 10.000$. Имеется возможность разместить рекламный ролик на радио (стоимость минуты эфирно времени на радио 500$) и/или на телевидении (стоимость минуты на местном TV равна 1000$). Имеются статические данные об эффективности маркетинговых каналов. Так 1 минута на телевидении в среднем обеспечивает рекламодателю 15 новых клиентов, а 1 минута на радио – 10 новых клиентов. Кроме того, все рекламодатели должны соблюдать местное антимонопольное законодательство, в рамках которого общая длительность транслированных по всем каналам рекламных роликов не должна превышать 15 минут в месяц.
Вопрос: каким образом максимально эффективно (по количеству новых клиентов) с учетом бюджетного и законодательного ограничения распределить рекламную кампанию между радио и ТВ?
Аналитический аппарат для принятия решений – «простые» методы
Каждый человек ежедневно принимает десятки, сотни и тысячи решений. Стоит ли вставать с кровати? Что приготовить на завтрак? Поехать на машине или на метро? Что надеть? И т.д. и т.п. Несомненно, именно принятые нами ранее решения по большей части определили то, какие мы есть сегодня: насколько успешны, счастливы, богаты. Кроме того, многие из нас принимают решения, оказывающие влияние и на других людей: нашу семью, организацию, общество. Все это делает процесс принятия решений человеком, как минимум, интересным и достойным изучения, т.к. всем нам хочется принимать больше правильных решений и меньше неправильных.
Для поддержки процедуры принятия решений у нас есть мощнейший и наиболее совершенный инструмент – человеческий мозг. Безусловно, что никакие иные инструменты не могут сравниться с ним в эффективности (соотношении принятых правильных и неправильных решений) в качестве универсального средства для принятия решений любых видов. В этой связи интересна «концепция» устройства человек мозга в виде совокупности двух полушарий, одно из которых (левое) позволяет мыслить «абстрактно» (строить сложные, «отвлеченные» от конкретных предметов и жизненных ситуаций логические конструкции), а другое (правое) – «конкретно» (фактические, хранить в сжатом виде жизненный опыт в виде ассоциаций действие-результат). Наличие этих двух инструментов позволяет человеку принимать решения основные одновременно на трезвом логическом расчете и на интуиции. У разных людей генетически может быть более развито одно из полушарий, это приводит к увеличению или уменьшению доли логики в принимаемых решениях за счет, соответственно, уменьшения или увеличения доли интуиции. Существенный дисбаланс в любую сторону в функционировании полушарий снижает общее качество принимаемых решений и подробно описан в житейских историях и анекдотах про математиков и блондинок.
Разработка ПО: пример бизнес-процесса из практики
В индустрии разработки программного обеспечения (ПО) существуют много различных методологий разработки, которые представляют из себя достаточно концептуальные видения того, как следует реализовывать проекты по созданию ПО. В качестве примеров таких методологий можно привести: Rational Unified Process (RUP), Microsoft Solution Framework (MSF), Extreme Programming (XP), Agile, Capability Maturity Model Integration (CMMI) и многие другие.
Разделяя важность методологии как основы для реальных бизнес-процессов, следует отметить разницу в понятиях методология и бизнес-процесс. Бизнес-процесс представляет из себя реализацию методологии, ее отдельных элементов или элементов нескольких методологий в конкретной организации при выполнении конкретных проектов и создании конкретных продуктов. Поэтому, создание бизнес-процесса разработки ПО на основе одной из существующих методологий является первой и важнейшей задачей компании, желающей заняться в том или ином виде созданием софта (для внешних заказчиков или своих внутренних нужд).
Как показывает опыт автора, вполне возможно создать небольшую группу разработки и начать делать софт и без четкого описания бизнес-процесса. Однако, когда число участников такой «неформальной» команды становится больше пяти человек, то потери от отсутствия четкого регламента становятся несопоставимо большими по сравнению с затратами на регламентацию бизнес-процесса и специализированное ПО для его автоматизации. Потери в данном случае могут быть как прямыми (например, бесконечные переделки одной и той же функциональности по причине несоответствия требованиям заказчика), так и косвенными (например, ухудшение психологической атмосферы в коллективе, связанное с непониманием зоны своей ответственности каждым участником команды).
В данной статье приводится пример бизнес-процесса разработки ПО, созданный автором на основе элементов нескольких методологий (наибольшее количество элементов взято из MSF) и собственного многолетнего опыта разработки и управления разработкой ПО. Данный бизнес-процесс ориентирован на ведение крупных проектов по разработке ПО на достаточно «зрелой» стадии, когда продукт уже может эксплуатироваться заказчиками и когда речь уже идет скорее о развитии и доработках функционала, а также устранении «багов», нежели о разработке «с нуля» небольших программных продуктов.
Сервисная поддержка: мониторинг эффективности
Послепродажная поддержка клиентов является важной составляющей CRM, оказывающей существенное влияние на лояльность потребителей. Если в центр поддержки невозможно дозвониться или же на решение несложных проблем уходят дни, то, очевидно, что мы будем избегать пользоваться продуктами и услугами такой компании, предпочитая ее конкурентам с более организованным сервисом.
Налаживание эффективной сервисной поддержки является приоритетной задачей конкурентной стратегии компании. При этом для планирования, построения и дальнейшего управления сервисом необходима возможность его описать и измерить при помощи количественных показателей.
Существуют различные модели и соответствующие метрики, предназначенные для описания процессов поддержки, родившиеся в разных областях (работа Call-центра, ИТ-службы предприятия и др.). Это накладывает определенные ограничения на использования каждой из этих моделей в качестве универсального средства описания сервиса.
В настоящей статье рассматриваются наиболее распространенные методологии и возможность использования их отдельных элементов для построения модели и показателей эффективности работы службы поддержки конкретной компании – первого этапа на пути создания или совершенствования эффективного клиентского сервиса.
Контакт-центр: методика описания бизнес-процессов
Внедрение новой системы начинается с понимания того, как будет встроена система в существующую или планируемую организационную и технологическую инфраструктуру. Иными словами, с описания существующих и проектирования перспективных бизнес-процессов, которые будут реализовываться при помощи внедряемой технологии.
Поэтому важное значение имеет методика описания и визуального представления бизнес-процессов. Подходов и методик к этому существует великое множество. В настоящей статье предлагается один из них, успешно применяемый в нескольких крупных проектах.
А начнем мы с четкой формулировки целей описания бизнес-процессов в проектах внедрения информационных систем, т.к. из них вытекают требования к методике и нотации.