Автор: Malcolm Chisholm
Дата публикации оригинала: 2008-03-05
Источник: сайт B-Eye-Network

Управление корпоративной информацией требует более чем восстановления прежнего статус-кво.

Идея проектов глубоко укоренилась в ИТ. Когда мы встречаем коллегу, которого не видели некоторое время, то, скорее всего, первым вопросом, который мы зададим ему, станет: “Над каким проектом ты сейчас работаешь?” Если мы подумаем о своей карьере, то увидим, что она развивается в рамках проектов, над которыми мы работаем. Мы сравниваем: один проект хорошо реализовывался, другой был обречён с самого начала, а в третьем была представлена новая технология. Всё это представляется так, как если бы сама работа над проектами не подвергалась сомнениям. Хотя есть причины поставить под сомнение разумность проектного подхода, и правильно будет спросить, подходит ли работа в рамках проектов для осуществляемого управления корпоративной информацией (Enterprise Information Management - EIM).

Если EIM должна быть горизонтальной функцией, используемой для управления активами данных предприятия, подобно управлению человеческими активами, осуществляемым отделом кадров, то проекты в рамках данной функции вызывают проблемы. Определенно можно сказать, что развитая функция EIM состоит из набора сервисов, которые постоянно находятся в распоряжении предприятия, поддерживаются устойчивой инфраструктурой и предоставляются в рамках чётко определённых бизнес-процессов. Нельзя сказать, что проекты не имеют никакого значения для EIM. Однако EIM вряд ли будет успешным, если оно будет просто совокупностью ресурсов с такими техниками, как моделирование данных, которые могут быть реализованы в общих ИТ-проектах, которые преимущественно являются самодостаточными. В краткосрочной перспективе такое управляемое проектами EIM может иметь значение и восприниматься как успешное, если сами проекты воспринимаются как успешные. Однако в долгосрочной перспективе ничего не делается для оказания помощи в управлении корпоративными информационными ресурсами. На самом деле, управляемое проектами EIM приводит только к “путанице в данных”, что сегодня характерно для многих предприятий, когда никто не знает очень многого о ситуации с данными, интеграция данных чрезмерно затруднена, а касающиеся данных вопросы в большом количестве содержатся в приложениях BI.

Что такое проект?

Тем не менее, проекты являются очень привлекательным способом работы. В конце концов, существуют специальные характеристики проектов в области ИТ. Основной характеристикой является то, что проекты в области ИТ ориентировались на разработку приложений. До 1990-х годов это означало, что такие проекты занимались разработкой заказного программного обеспечения для оперативных систем. В данном контексте был создан и получил признание жизненный цикл разработки системы (SDLC) как способ, с помощью которого выполнялись ИТ-проекты. Имелись, конечно, и сопутствующие принципы, однако, как и SDLC они ориентировались на создание заказного программного обеспечения. SDLC заключается в хорошо известном принципе “водопада”, когда заканчивается один этап и начинается другой, который проходит через этапы потребностей, анализа, дизайна, разработки программ, тестирования, реализации и поддержки продукции. Иногда происходили отклонения от этой схемы, однако способ водопада SDLC определял ИТ-проекты в течение многих лет и продолжает их определять в настоящее время.

Использование подхода SDLC, кажется, имеет тесную связь с проектами. Существуют фазы, которые являются кульминационными во внедрении системы. С этой точки зрения проект имеет существенное значение для “разработчиков” и “архитекторов”. Что бы ни было представлено в проекте – это реализуется в продукте и становится подотчётным другой ИТ-области, такой как контроль за продуктами, а также поддерживается таким способом, который не похож на проект.

Важным в подходе SDLC является то, что он на самом деле не определяет сам проект, а его определение важно для обсуждения проектного подхода. Мне посчастливилось, что значительная часть моей карьеры была связана с работой в агентствах развития Организации Объединенных Наций. Эти агентства финансируют и управляют проектами в странах третьего мира, которые направлены на социальное и экономическое развитие этих стран. Так как их работа связана с проектами, то агентства долго и напряженно думали над тем, что такое проект. Они пришли к заключению, что важными характеристиками проекта являются даты начала и завершения его реализации, цели, затраты, отдача и результат. Я предполагаю, что этот набор характеристик так же хорошо как для проектов социально-экономического развитии, подходит и для проектов по разработкам систем.

Проекты, собственность и Адам Смит

Однако в ИТ проектный подход может быть проблематичным. Я наблюдал, что он приводит к созданию такой ситуации в отношении разработчиков и архитекторов, когда эти профессионалы переходят от одного проекта к другому, не становясь полностью “собственниками” того, что они создают. К сожалению, это еще более верно для консультантов, которых берут на работу только на срок реализации проекта. Это отсутствие привязки к проекту вместе с тем фактом, что ты на самом деле не “являешься собственником” чего-либо, приводит к тому, что люди избегают ответственности – возможно не намеренно, однако, тем не менее, всё происходит именно таким образом. Системы вводятся в промышленную эксплуатацию, и если позже обнаруживается, что они не отвечают требованиям, то их нельзя вернуть команде разработчиков, потому что все эти разработчики уже трудятся над какими-то новыми проектами. Концепцию “собственности”, конечно, довольно тяжело определить. Обычно разработчики не имеют права собственности на тот продукт, который они разработали, однако то, как он используется, предполагает высокий уровень ответственности. Этот уровень ответственности не может существовать, если разработчики не проявляют заботу о сохранности того продукта, который они производят. Ответственность заканчивается, когда заканчивается реализация проекта.

Все это в какой-то мере противоречит теории разделения труда, которая известна со времен Адама Смита. Эта известная теория 18 века утверждает, что отдельному человеку требуется намного больше времени для производства булавки, чем группе людей, каждый человек в которой специализируется на производстве одной части булавки. Эта была основная концепция, которая неоднократно с большим успехом применялась в промышленную эру. Но применима ли данная концепция к информационной эре? Является ли создание системы, а затем ее предоставление организационной единице для организации её выполнения тем же подходом, который использовался и при отрезании куска проволоки и передаче его другой группе людей для обработки?

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

Проекты для всего

Несколько десятков лет назад разработка встроенных систем была широко распространена. Однако с 1990-х годов продажи COTS (готовых программных решений) стали более привычными. Сегодня меньше внимания уделяется созданию или покупкам новых приложений, а гораздо больше – интеграции существующих активов данных. Это может наблюдаться в таких областях как бизнес-аналитика и управление основными данными.

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

Новый подход

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

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


Для удобства отслеживания новых публикаций рекомендуем подписаться на рассылку или на канал RSS.

Читайте также: