Методология управления BI-проектами в консалтинговой компании

Тимофеев А.Н.
Выпускник группы ITM-20
Школа IT-менеджмента
РАНХиГС при Президенте РФ

Компания, в которой в настоящее время работает автор, в течение уже более 20 лет занимается как продажей лицензий программных средств, так и проектной деятельностью по созданию информационно-аналитических систем масштаба предприятия для различных заказчиков (банки, крупные торговые компании, предприятия  энергетики, нефтегазодобывающие компании, телеком). В большей части проекты выполняются с использованием  линейки продуктов SAP Business Objects. Такие проекты, как правило, включают в себя разработку моделей хранилищ, витрин данных, расположенных в различных СУБД и разработку процедур загрузки данных из любых источников (различные СУБД, Excel, XML, текстовые файлы со структурированными данными). Процедуры загрузки данных разрабатываются с использованием профессиональных ETL-средств (IBM Data Stage или SAP BusinessObjects Data Services). Разработка отчетов выполняется в среде линейки продуктов SAP BusinessObjects.

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

ОСОБЕННОСТИ ПРОЕКТОВ ПО РАЗРАБОТКЕ BI-ПРОЕКТОВ В КОНСАЛТИНГОВОЙ КОМПАНИИ

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

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

Если со стороны заказчика есть требования, что управление проектом ведется по любой известной методике или на основании его внутренних требований по ведению проектов, то мы, естественно принимаем все требования заказчика. Но если  их нет, то молодому руководителю проекта надо иметь свои «корпоративные рекомендации»: что, в какой последовательности необходимо делать, роли участников проекта, какие документы в ходе проекта необходимо будет подготовить, чтобы удовлетворить все требования заинтересованных сторон со стороны заказчика. И выдать в конце проекта гарантированный результат, а именно некий BI-продукт, который бы не только удовлетворял бы всем функциональным и техническим требованиям, но и гарантировал высокую степень удовлетворенности и лояльности клиента. Чтобы сотрудники заказчика не только сказали «огромное спасибо» разработчикам, но и продолжали тесно сотрудничать с компанией еще не один год. Сама методика ведения BI-проекта представлена в Аттестационной работе, здесь же я хотел бы остановиться на тех моментах, на которые в обязательном порядке должен обратить внимание новоиспечённый руководитель BI-проекта.

Проекты в области внедрения BI имеют свою специфику. В первую очередь их отличает то, что результаты BI-проекта практически всегда отличаются от тех видений, которые были у самого заказчика до начала проекта ввиду того, что его сотрудники не владеют теми BI-инструментами, которые мы им предлагаем. После первых результатов со стороны пользователей заказчика постоянно увеличивается количество «хотелок», т.е. масса дополнительных требований вносится уже в процессе разработки. Именно поэтому в таком проекте постоянно меняются все планы, и именно поэтому здесь в общем случае мало подходят стандартные и всем известные методологии управления проектами от PMI или IPMA, основанные на жестком планировании и контроле выполнения планов. Хотя многие области знаний, некоторые группы процессов, рекомендации по проектной документации, несомненно, не только можно, но и нужно смело брать на вооружение из известных стандартов или ГОСТ.

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

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

Менеджер проекта всегда должен сказать: «Мы можем сделать вам «Это», «Быстро» и «За дешево».  Но вы (заказчик) должны выбрать одно из них» [5]. Нельзя приступать к проекту, пока не определены приоритеты:  или это рамки проекта, или стоимость, или сроки. И если произошло значительное увеличение требований заказчика, отказаться от них нельзя – что делать в этом случае менеджеру проекта? Надо договариваться с заказчиком либо об изменении сроков проекта, либо стоимости, чтобы на дополнительные работы привлечь необходимые ресурсы. А если заказчик требует уменьшить сроки сдачи проекта – это либо уменьшение функциональности, либо опять же, увеличение бюджета, в зависимости от того, что для заказчика приоритетней. Если приоритеты меняются в ходе проекта, это обязательно должно быть известно менеджеру проекта, причем считается, что всё, что сделано до изменения данного решения, всё было сделано правильно.

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

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

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

Еще один совсем свежий пример. Наша компания разрабатывала ряд информационных панелей для финансового директора компании «Фортум» (бывшая «ТГК-10»). После показа пилот-проекта «отечественного» финансового директора меняет немец. Далее по требованию нового CFO в значительной мере пришлось переделывать дизайн. Из всех информационных панелей были удалены все спидометры, переделаны графики и т.д. Но при этом проект получил очень высокий статус, была проделана неимоверная работа совместно со специалистами заказчика по сбору и выверке данных в SAP BW. В итоге проект был успешно сдан, мы получили очень высокую оценку. В качестве примера, чтобы было понятно о чем идет речь, приведу одну из основных информационных панелей на Рис.1. Т.е проект получился очень интересным и нам, как разработчикам, было чем гордиться. Благодаря этому проекту в нашем арсенале появилось много новых различных идей и приемов.

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

Рис.1. Информационная панель для компании «Фортум»

Программисту всегда обидно, когда его труды выбрасываются в корзину.

И только через несколько месяцев раздался звонок из Челябинска, обещали вернуться к этой системе. Но пока всё ждем заявку на доработку проекта от заказчика, ждем нового спонсора проекта.

Основная задача аккаунт-менеджера в политическом проекте (с долей юмора «человека − железная печень») является налаживание непосредственного контакта со спонсором. Основная задача руководителя такого проекта – поддержка этих отношений.

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

При большой заинтересованности со стороны заказчика выступать с исполнителем в качестве партнера, а не диктатора, проект может иметь и инновационный стиль, или, хотя бы, некую инновационную составляющую, которая может и должна обеспечить гарантированный успех BI проекта. Таких примеров в копилке нашей компании довольно много. В 2008 году нас пригласили в ОАО «Сургутнефтегаз» и предложили разработать несколько BI-систем по оперативной и аналитической отчетности. Успешно реализовав несколько проектов, мы совместно со специалистами Сургутнефтегаза сейчас участвуем в инновационных работах по внедрению новейшей СУБД SAP HANA. В таком развитии этого проекта заказчик уже выступает не как «диктатор», а как партнер, повышается статус управления проектом. Но перетекание из политического стиля в инновационный возможен только при долгосрочном партнерстве заказчика и исполнителя. Теперь обе компании несут ответственность и проявляют полную заинтересованность в результатах полученного продукта, никакая смена спонсора проекта не приведет к срыву. Но появляются другие риски, связанные с малым опытом внедрения, вернее, с его полным отсутствием. Обучаться придется как нам, так и сургутянам в «боевых условиях».

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

Если обе стороны уже давно работают вместе, либо проект перетекает в инновационный, в большем предпочтении оказывается рамочное соглашение, т.е. контракт Time&Material, в котором для каждой стороны определяются источники формирования бизнес эффектов и принципы разделения рисков, а также принципы организации совместной работы. Оплата производится по так называемым TimeSheets − реальному времени работы консультантов на проекте.

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

Что берем на вооружение?

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

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

Спиральная модель обеспечивает большую гибкость в управлении проектом. Ведь что такое  в итоге «управление проектом» − это всегда поиск компромисса между «Что?», «Когда?», «За сколько?», «Чем?», «Зачем?» [5]. Т.е. между целью, сроками и стоимостью,  исполнителем, инструментальными средствами и технологией. И на каждом этапе итерации это всегда можно обсудить с заказчиком и по результатам и внесенным изменениям можно внести коррективы в любой из этих вопросов. Таким образом, существенно упрощается процесс внесения уточнений и дополнений в проект, что в значительной мере уменьшает риски неудачи проекта.

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

Многолетний опыт разработки BI-проектов позволяет безоговорочно подписаться под идеями Agile Manifesto, которыми мы, несомненно, руководствуемся в своей работе (Manifesto for Agile Software Development) [10]:

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

Rational Unified Process (RUP) вполне может вместить agile-ценности и дополнить другие agile-процессы. Поэтому от Rational Unified Process мы берем набор лучших практик по разработке систем, выбираем из них те, которые лучше вписывается в наши проекты. И далее его можно дополнить рекомендуемыми проектными документами.

Заключение

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

Ответственность – готовность брать на себя полностью или частично последствия принятых решений. Прежде чем соглашаться на роль руководителя проектом, с любой стороны, надо внимательно проанализировать все ответственности, которые на вас возлагает спонсор проекта, нарисовать для себя таблицу и поставить соответствующие им полномочия, которые, по вашему мнению, должен предоставить вам спонсор по каждой ответственности. Чаще нам говорят: «Ты отвечаешь за проект» – это ни о чем. Например, если руководитель проекта берёт на себя ответственность не только за результативность, но и за рентабельность, он должен иметь право обсуждать с заказчиком цену, иметь возможность влиять на себестоимость, выбирать ресурсы. По каждой ответственности должен стоять тезис: «Для того чтобы … надо …».  Как и любой менеджер в любой области руководитель проекта не может отвечать за то, чем он не управляет [5].

Успех любого менеджера проекта целиком и полностью зависит от проектной команды. Именно поэтому он должен пользоваться заслуженным авторитетом у своих коллег. Заслуженный авторитет состоит на 50% из профессиональных качеств, на остальные 50%  из человеческих качеств. Скорее всего, здесь и объяснять больше нечего. Только если у руководителя есть оба «50%», только в этом случае он руководитель на все «100%».

Список использованной литературы

• Минцберг Г., «Структура в кулаке. Создание эффективной организации». –  СПб.: Питер, 2001.
• Ананьин В.И., IT-Менеджмент. Учебный курс. – М.: АНХ, 2011 г.
• Ананьин В.И., «К КОНКУРЕНТНОМУ ПРЕИМУЩЕСТВУ – ЧЕРЕЗ ПРОЕКТЫ». Журнал «Управление проектами и программами», 03(23) 2010.
• Леоненков А.В., Рациональный унифицированный процесс. Учебный курс. – М.: АНХ, 2011 г.
• Сирота В.Е., Управление проектами искусство достижения целей. Учебный курс. – М.: АНХ, 2012 г.
• Якобсон А., Буч Г., Рамбо Дж. «Унифицированный процесс разработки программного обеспечения». – СПб.: Питер, 2002. – 496 с: ил.
•  «A guide to the Project Management Body of Knowledge», 2000 Edition, Project Management Institute, Newtown Square, Pennsylvania USA.
• IPMA Competence Baseline (ICB), Version 2.0b, Bremen, 1999/2001, International Project Management Association.
• Единая система стандартов автоматизированных систем управления. АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. ГОСТ 24.601-86.
• Материалы сайта www.agilemanifesto.org