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

'''''«Имейте мужество пользоваться собственным умом»'''''

'''''Иммануил Кант'''''


;[[:Категория:Владимир Рахтеенко (Статьи)|Владимир Рахтеенко]]: Генеральный директор CUSTIS

''Статья, январь 2011''

=== ИТ и разные подходы к управлению бизнесом ===
Граница между большими «готовыми» и «заказными» корпоративными системами не так очевидна, как принято считать. Чтобы убедиться в этом, попробуем для начала разобраться, кто является их покупателем. В этой связи уместно вспомнить два характерных подхода к управлению.

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

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

Очевидно, что все новые подходы ведения бизнеса создаются компанией с целью улучшения своих рыночных позиций и, по сути, являются ее ноу-хау. Поэтому любое ИТ-решение, присутствующее на рынке, сможет удовлетворить потребности организации «предпринимательского» типа в лучшем случае процентов на 80. Для реализации оставшихся 20 процентов запросов систему придется дорабатывать или, как в последнее время часто говорят, — кастомизировать. И компании готовы идти на такой шаг, так как прекрасно понимают, что выгоды от ИТ-проекта с высокой степенью кастомизации несоизмеримо больше затрат на него, хотя объем необходимых в таких проектах инженерных работ очень велик. Дальше речь пойдет о проектах именно такого типа.

=== Уговор дороже денег ===

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

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

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

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

=== В Греции все есть? ===

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

При оценке объемов, а значит и стоимости предстоящих доработок, необходимо учитывать две вещи: требуемый новый функционал и размер инструмента (прототипа). Приведем простой модельный пример. Предположим, что для решения поставленных задач мы можем выбрать из трех прототипов (для простоты A, B и С). У каждого прототипа есть две характеристики: необходимый объем доработок и объем имеющегося в нем функционала. Количественные значения в условных единицах по каждому прототипу представлены в таблице ниже:

{| cellspacing="0" cellpadding="0" border="1"
|
| &nbsp;&nbsp;&nbsp;А
| &nbsp;&nbsp;&nbsp;В
| &nbsp;&nbsp;&nbsp;С
|-
| Объем доработок до желаемой системы (v)
| &nbsp;&nbsp;300
| &nbsp;&nbsp;250
| &nbsp;&nbsp;&nbsp;200
|-
| Объем прототипа (V)
| &nbsp;&nbsp;200
| &nbsp;&nbsp;500
| &nbsp;1000
|-
| Итоговая стоимость доработок (условные единицы)
| &nbsp;&nbsp;&nbsp;84
| &nbsp;&nbsp;&nbsp;94
| &nbsp;&nbsp;&nbsp;100
|}

Итоговая стоимость инженерных работ будет функцией двух значений из каждого столбца следующего вида: (V+v)<sup>n</sup> — V<sup>n</sup>, где 1,5≤ n≤ 2.

В результате, парадоксальным образом дешевле оказывается вариант А, когда нужно сделать больше изменений на меньшем исходном функционале. Приведенный пример наглядно показывает, что при выборе инструмента, который будет сильно доработан, необходимо учитывать оба параметра — V и v. А истина как всегда где-то посередине: слишком малый прототип — неэффективно дорабатывать, очень большой — тоже неэффективно.

Стоимость разработки одной и той же новой функции в системах с объемами прототипов V и 4V будет соответственно равна 1 у.е. и 3 у.е., а для V и 16V — 1 у.е. и 6 у.е.

Заметим, что пока мы рассматривали ситуацию в статике. Реально и сама системная архитектура и, значит, объем доработок со временем меняются. Как показывает наша практика, при выборе прототипа более уместен лозунг «Ничего лишнего!», а не традиционный «В Греции все есть» — избыточный функционал придется протаскивать через все доработки.

=== Без людей нет идей ===

Третьим существенным риском при внедрении информационной системы с высокой степенью кастомизации оказываются люди, чьими руками будет реализован проект. Успех серьезно зависит от того, насколько персонал, который будет делать инженерные работы, знает инструмент и умеет обращаться с ним. Другими словами — насколько далеко исполнители отстоят от идеологов прототипа системы. Чем ближе они к идеологам и авторам инструмента, тем лучше они умеют им пользоваться и тем скорее они сделают работу эффективно. Чем длиннее цепочка от авторов до внедренцев, тем больше потери знаний к ее концу. В идеале, внедрение системы должны делать авторы. Но так как это не всегда достижимо, авторы, по меньшей мере, должны быть доступны в проекте. Если они вообще не доступны, качество проекта сильно снижается, не говоря о кратном увеличении объема инженерных работ (v).

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

=== Жизнь только начинается ===

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

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

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

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

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

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

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

=== В сухом остатке ===

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

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

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

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

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

Заказчик должен стремиться получить под свой контроль: 100 % эксплуатации, 80 % сопровождения, 20 % развития информационной системы. Это оптимальная ситуация, как с точки зрения рисков, так и с точки зрения затрат на ИТ. Однако, в зависимости от бизнес-приоритетов заказчика, возможны разные варианты. Но всегда на стороне заказчика правильно оставлять два обязательных процесса: 1) контроль над системной архитектурой, который позволяет полностью определять логику своего развития, 2) самостоятельную эксплуатацию всех значимых ИТ-систем, что сильно снижает операционные риски, а также повышает качество внедрений.

[[Категория:Владимир Рахтеенко (Статьи)]]
[[Категория:2011 год (Статьи)]]
[[Категория:CNews (Публикации)]]

{{replicate-from-custiswiki-to-lib}}