Да, вы проделали большую работу и повод для праздника все же есть. Однако самое время также ощутить всю тяжесть ответственности, легшей на ваши плечи.
По словам вице-президента The Data Warehousing Institute по технологиям Уэйн Эккерсон, зачастую причина проблем, возникающих после реализации хранилища данных, кроется в ошибках, "допущенных на более ранних этапах". Например, вы не привлекали к работе над созданием хранилища пользователей, не добились должного понимания со стороны высшего руководства и т.д. Однако многие трудности либо неизбежны, либо, как это ни парадоксально, являются следствием слишком хорошо проделанной работы.
Итак, неожиданно стало ясно, что работа по строительству хранилища данных вовсе не закончена (да и вряд ли когда-нибудь вообще будет завершена).
Как бороться с трудностями, возникающими после внедрения системы? Вот мнение некоторых специалистов.
Испытание #1: Бизнес меняется
"Ваш бизнес будет меняться. Подготовьтесь к этому, - предупреждает Джефф Гентри, консультант по системам Computer Systems Authority. - Естественно, это означает, что параллельно должно модифицироваться и хранилище данных".
Смысл создания хранилища данных - возведение моста между информационными потребностями компании и накапливаемыми ею данными. "И потребности, и данные ежедневно трансформируются", - говорит Дуглас Хэкни, консультант в области хранилищ данных, президент компании Enterprise Group.
Как правило, первым предупредительным сигналом служит рост числа запросов на модификацию хранилища. Чтобы справиться с этим, необходимо разработать и внедрить процессы для обработки таких запросов. "Мы привыкли к тому, что изменения в информационных системах происходят под влиянием развития технологий или накопления данных. Однако развитие хранилища данных в большой степени опирается на бизнес-процессы, - говорит Хэкни. - После внедрения хранилища данных непрерывно начнут поступать запросы на модификацию, и все они будут обоснованными. Необходимо приспособиться к этому".
Будьте готовы также к трудностям, которые, как это ни парадоксально звучит, являются следствием успеха системы. Если пользователи "забрасывают" вас все новыми требованиями, вероятно, это связано с тем, что вы сделали все слишком хорошо. Что делать в таком случае? "Готовьтесь к тому, что это может произойти, и планируйте свои действия соответственно", - говорит Дон Штоллер, директор службы поддержки принятия решений компании Owens & Minor, занимающейся оптовой торговлей медицинскими товарами.
Штоллер знает, что говорит. Первый этап проекта по созданию хранилища данных в Owens & Minor был завершен в прошлом году. Продавцы получили возможность доступа к полной информации по клиентам и поставщикам - от первоначального контакта до выписки счета. Хотя изначально по завершении первого этапа планировалось перейти к другим функциональным областям - маркетингу, финансам и дистрибуции, с этим пришлось повременить.
"Мы просто не были готовы к тому, что пользователи проявят такой энтузиазм", - говорит Штоллер (за реализацию проекта он был удостоен специальной премии Data Warehousing Institute). Чтобы успевать вносить изменения, предлагаемые пользователями, Штоллеру пришлось замедлить ход работ по подключению остальных отделов к хранилищу.
Почему нельзя было ввести проект в действие на всем предприятии, а уж потом приступать к модификации? "После запуска хранилища данных энтузиазм со стороны пользователей способствовал повышению продуктивности нашей работы; мы не хотим упускать этот шанс", - говорит Штоллер.
Одна из задач, стоящих перед Штоллером, - правильно расставить приоритеты. Каждую неделю он проводит специальные со своими сотрудниками, а также с представителями пользователей, а раз в месяц на встрече с руководством компании отчитывается о достигнутых результатах и предлагает новые планы.
Испытание #2: Технологии меняются
Развитие технологий также может вызвать необходимость в модификации уже работающего хранилища данных.
"Мы постоянно вносим какие-то изменения", - говорит Ларри Смит, старший менеджер проекта в области хранилищ данных WarehouseMCI, который реализуется в телекоммуникационной компании MCI Communications. Система помогает отследить, какие услуги чаще заказывают клиенты, как ими пользуются и как меняются предпочтения заказчиков. WarehouseMCI был спроектирован четыре года назад, а в действие введен в 1996 году.
Успех проекта оценила как сама MCI (после ввода WarehouseMCI в эксплуатацию объем продаж компании повысился на 20%), так и ее клиенты, в интересах которых компания и проводит анализ затрат и выгод от использования услуг связи. Тем не менее в настоящее время полным ходом идет коренная реорганизация всего хранилища данных, от технологического фундамента до конкретных процедур.
"Я знал, что рано или поздно придется что-то перепроектировать, но не думал, что изменения окажутся настолько серьезными, - говорит Смит. - За последний год появилось множество новых технологий и инструментов. Строение хранилища данных необходимо периодически пересматривать".
Испытание #3: Неослабевающий интерес персонала ИС
Необходимость непрерывного обновления зачастую ведет к падению заинтересованности разработчиков в проекте.
"Пока идет создание хранилища данных, участники проекта проявляют живейший интерес к новым инструментам и технологиям, - говорит Штоллер. - Однако с началом эксплуатации системы он пропадает".
"В создании хранилища данных обычно стремятся принять участие самые талантливые специалисты, - добавляет Хэкни. - Но эти же сотрудники с гораздо меньшей охотой берутся за обслуживание системы".
Чтобы избежать падения заинтересованности, Смит постоянно перераспределяет задачи между своими подчиненными и нагружает их новыми обязанностями. "Необходимо все время предлагать им что-то новое", - говорит Смит.
Испытание #4: Жалобы пользователей на то, что с предоставленными инструментами сложно работать
"Мнения разработчиков и пользователей относительно удобства инструментария зачастую не совпадают", - говорит Бенджамен Тауб, главный архитектор хранилищ данных Dataspace, консалтинговой компании, которая специализируется на создании хранилищ данных. Однажды Тауб принимал участие в создании дорогостоящей многоуровневой биллинговой системы, с которой пользователи "отказались иметь дело" после ввода ее в эксплуатацию. Стремясь вовремя завершить работу над проектом, создатели упустили из виду проблему практического обучения пользователей, которые не были знакомы с визуальным интерфейсом и не умели составлять запросы. Кроме того, они привыкли получать ежемесячные отчеты в виде распечаток.
По словам Тауба, при оценке простоты инструмента необходимо учитывать прежде всего точку зрения пользователя. Правда, это не так просто, как кажется. Специалист, привыкший работать с современными инструментами, не всегда понимает, насколько сложными они могут показаться новичкам.
"Существует тенденция навязывания пользователям наиболее мощных и современных инструментов, - подтверждает Эккерсон. - Однако на первом этапе лучше предложить то, что им уже знакомо. Специалисты болезненно воспринимают любой вынужденный шаг назад". Иными словами, если пользователи привыкли читать ежемесячные отчеты в печатном виде, сразу отказываться от них не следует. Тем самым, по словам Эккерсона, вы обеспечите плавный и естественный переход к новому, автоматизированному и гораздо более эффективному способу доступа к данным.
"Если вы не построите мост из старого мира в новый, пользователи никогда не смогут преодолеть пропасть между ними", - добавил Эккерсон. Созданием как раз такого моста занимается Кевин Перес, руководитель консультативного отдела страховой компании Metropolitan Life Insurance. Хотя Перес не сомневается в компетентности своих пользователей, он не заставляет их работать с инструментами для составления сложных запросов.
Реальная необходимость в этом есть лишь у бухгалтеров; все остальные по-прежнему получают отчеты на бумаге. Как говорит Перес, главное не в том, чтобы дать каждому по лопате для копания в данных, а в том, чтобы предоставлять нужную информацию, обеспечивая экономию и высокую эффективность.
Испытание #5: недостоверные или устаревшие данные
Если на запросы к хранилищу данных пользователи получают совсем не те результаты, на которые они рассчитывали, значит, случилось худшее из того, что может произойти. Тогда доверие к системе утрачивается и хранилище данных фактически умирает.
Возможно, с самими данными все в порядке. Возможно, виной всему неудачная классификация данных или несвоевременная синхронизация с разнородными системами. Последнее может привести к серьезным последствиям, особенно если информация в хранилище пополняется преимущественно за счет подразделений компании.
Это серьезная проблема. А что делать, если уже действующее хранилище содержит ошибочные данные? Необходимо провести тщательную и исчерпывающую проверку.