Управление проектами по внедрению информационных систем с использованием элементов методологий RUP и ARIS

Т.Ю. Андреева
Выпускница группы ITM-23A
Школа IT-менеджмента РАНХиГС при Президенте РФ
Кофемания
Директор департамента информационных технологий
г.Москва

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

Однако компания растет, система, которая когда-то казалась такой простой и понятной, наполняется функционалом, и начинают возникать внутренние коллизии:

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

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

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

А что же с информационными технологиями? Они, как известно, всегда отражают структуру и дух компании с тем, чтобы предлагать IT-сервисы, наиболее адекватные  и востребованные бизнесом на каждой стадии его развития. Данный случай не был исключением. Ниже перечислены характерные особенности корпоративной информационной системы (КИС), которая была построена за годы развития компании.

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

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

• Стратегия внедрения – “Натягивание системы на существующий бизнес”.

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

• «Требования слабо согласованы и сильно изменчивы. Они в большей степени отражают не стратегию бизнеса, а внутреннюю конъюнктуру отношений подразделений заказчика.»
• «Большой объем дополнительных разработок, который не редко искажает интеграционную схему приобретенной ERP системы. Это в свою очередь, иногда приводит к серьезным проблемам с технической поддержкой от производителя.»

Это действительно серьезная проблема. Например, переработанная изначально 1С-бухгалтерия для решения задач управленческого учета, оказалась непригодна к дальнейшему развитию. Поэтому при выборе очередной программной системы, особое внимание уделялось ее гибкости и интеграционным возможностям. Здесь важно находить компромиссные решения, оптимальные для конкретной компании. Слишком большой объем дополнительных разработок приводит к проблемам с внешней поддержкой, но отсутствие необходимых «тонких» настроек или их недостаточное количество, ограничивает гибкость бизнес-процессов, а также возможности компании вырабатывать свои «know how».

• «Итоговая архитектура получаемого решения похожа на “лоскутное одеяло“, которое является зеркалом конъюнктуры внутренних отношений заказчика.»

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

Управление проектом

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

Высокая степень неформальности политического проекта действительно препятствует задачам документирования и регламентирования. Эта одна из ключевых причин возникновения кризисной ситуации с внедрением новых сервисов и систем. Многообразие задач неумолимо требует выработки общего языка формулирования требований, способов фиксации и оценки результатов, стандартизации  процессов инициирования и проведения проектов. Но при том, что необходимость подобных преобразований признается высшим менеджментом, практическая реализация их буксует из-за непривычки к каким-либо иным способам коммуникаций, кроме неформальных. Чтобы выйти из «замкнутого круга», был предложен компромиссный способ документирования – посредством графических диаграмм. Любой визуализированный документ более привлекателен и понятен, чем текстовый, так что идея заменить большую часть формальных тестовых документов на графические диаграммы нашла хороший отклик в компании. Для реализации этой идеи был выбран инструментальный пакет ARIS, как наиболее популярный, универсальный и перспективный. Что же касается процессов ведения и управления проектами, то было решено обратиться к методологии Rational Unified Process (RUP). Говорить о полноценном внедрении RUP в компании, было бы сильным преувеличением. Однако основные принципы этой методологии, такие как: организация работы в команде, активное использование use case моделей, управление требованиями, управление изменениями и рисками, итерационность и инкрементальность,  хорошо легли на почву, уже вспаханную и подготовленную многолетней практикой. Флаг RUP был поднят, и теперь каждый существенный этап проекта начинается с вопроса «А что по этому поводу говорит RUP?».

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

Кампания по «вживлению» духа RUP и популяризации графических методов разработки регламентных документов продолжается уже несколько месяцев, так что можно оценить первые результаты:

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

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

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

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

Причем, представители бизнес подразделений играют активные исполнительские роли (тестирование, внедрение, документирование и т.д.), а не только контролирующие и управленческие.

• Узаконено понятие  «инкрементальность»  при внедрении проектов.

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

• Узаконено понятие  «итеративность».

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

• Была предложена общая терминология внутри проектов

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

• Было предложено использование моделирования среде ARIS

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

• Впервые были четко разграничены этапы разработки (написание программного кода или настройки/конфигурирования промышленной программной системы) от этапов тестирования и внедрения.

Для IT-подразделений, функционирующих внутри непрофильного бизнеса, часто трудно аргументировать затраты на тестирование и внедрение. Здесь снова помогает ссылка к общепризнанным авторитетным источникам, а именно методологиям RUP и ARIS, которые не только детально специфицируют перечень всех работ, но и разъясняют их смысл. Теперь работам по тестированию и внедрению посвящены две последние фазы регламентного процесса ведения проектов. Причем процесс тестирования делится на три этапа: тестирование в лабораторной среде, тестирование в промышленной среде и начало промышленной эксплуатации как последняя фаза тестирования.

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

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

• Созданы серьезные предпосылки для внедрения процессного подхода к управлению компанией.

Список использованных источников

• В.Ананьин «В поисках “правильного” стиля  ИТ проекта», журнал “Управление проектами”, Март 2007 № 1 (6)
• Кролл П., Кратчен Ф. Rational Unified Process – это легко.Руководство по RUP.: Пер. с англ. – М.: КУДИЦ-ОБРАЗ, 2004. – 432 с.: ил.
• Крачтен Ф. Введение в Rational Unified Process. Пер. с англ. – М.:Вильямс, 2002. – 240 с.: ил.
• Г. Минцберг, “Структура в кулаке. Создание эффективной организации”, Питер, СПб, 2001.
• В.В.Ильин «Реинжиниринг бизнес-процессов с использованием ARIS» - M.: ООО «Вильямс», 2008. – 256 с. : ил.
• «Манифест гибкой методологии разработки программного обеспечения»http://agilemanifesto.org/ (http://agilemanifesto.org/iso/ru/ - русский перевод)
• И.В. Войнов, С. Г. Пудовкина, А. И. Телегин “ Моделирование экономических систем и процессов
• Хаммер М. «Реинжиниринг корпорации: Манифест революции в бизнесе», пер. с англ. ЮЕ.Корнилович. – М.: Манн, Иванов и Фербер, 2011. – 288 с.