При централизованном подходе

РАЗВЕРТЫВАНИЕ СНИЗУ ВВЕРХ

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

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

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

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

Централизованный подход также облегчает компаниям задачу обеспечения согласованности и единства определений показателей и правил их исчисления, потому что они хранятся в одном месте и обслуживаются одной командой (такое хранилище определений показателей может называться словарем данных, библиотекой данных или глоссарием данных; технические команды называют его хранилищем метаданных). Еще одно преимущество централизованного подхода — возможность поддержки той же бизнес-аналитической инфраструктурой других аналитических приложений (помимо приложений панели индикаторов). Например, Quicken Loans создавала свою архитектуру бизнес-анализа в первую очередь для управления своими операционными панелями индикаторов, но теперь с успехом использует ее и для поддержки других аналитических приложений.

Стандарты для систем

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

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

Стандарты для приложений

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

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

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

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

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

Стандарты для данных

Помимо стандартизации приложений техническая команда нуждается и в стандартизации данных. Ее можно обеспечить тремя способами: 1) создав модель данных для панели индикаторов; 2) осуществляя выборку подходящих данных их эксплуатационных систем, файловых систем и др., причем как внутри, так и вне организации; 3) пугем очистки и верификации данных, чтобы гарантировать их соответствие ожиданиям пользователей в отношении качества и точности.

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

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

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

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

«Мы купили (продукт у поставщика) ради его модели данных, которая позволила нам с самого начала сделать резкий рывок вперед. Она помогла нам понять, как нужно обращаться с этим материалом. Теперь этот продукт составляет только 20% нашего полного решения, но полезно было иметь что-то, с чего можно было начать», — говорит старший менеджер по информационным технологиям из компании, работающей в секторе беспроводных телекоммуникационных систем.

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

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

Дата добавления: 2015-04-29