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

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

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


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

''Статья, ноябрь 2011.''

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

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

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

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

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

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

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

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

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

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

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

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

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

{| cellspacing="0" cellpadding="0" border="1"
|
| &nbsp;&nbsp;&nbsp;А
| &nbsp;&nbsp;&nbsp;В
| &nbsp;&nbsp;&nbsp;С
|-
| Объем прототипа (V)
| &nbsp;&nbsp;200
| &nbsp;&nbsp;500
| &nbsp;1000
|-
| Объем доработок до желаемой системы (v)
| &nbsp;&nbsp;300
| &nbsp;&nbsp;250
| &nbsp;&nbsp;&nbsp;200
|-
| Итоговая стоимость доработок (у.е.)
| &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 (в соответствии с моделью оценки стоимости разработки программного обеспечения COCOMO).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[[Категория:Владимир Рахтеенко (Статьи)]]
[[Категория:2011 год (Статьи)]]
[[Категория:CUSTIS (Заказные ИнформСистемы)]]

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