|
Имейте мужество пользоваться собственным умом, или Как организовать эффективную работу над ИТ-проектом — различия между версиями
Материал из CustisWiki
|
|
| (не показаны 4 промежуточные версии 3 участников) | | Строка 6: |
Строка 6: |
| | ;[[:Категория:Владимир Рахтеенко (Статьи)|Владимир Рахтеенко]]: Генеральный директор CUSTIS | | ;[[:Категория:Владимир Рахтеенко (Статьи)|Владимир Рахтеенко]]: Генеральный директор CUSTIS |
| | | | |
| − | ''Статья, январь 2011.'' | + | <blockquote> |
| | + | ''В декабре 2011 года эта статья с небольшими сокращениями опубликована на сайте [http://www.forbes.ru/ Forbes] в рубрике [http://www.forbes.ru/svoi-biznes/master-klass Свой бизнес / Мастер класс] |
| | + | под названием [http://www.forbes.ru/svoi-biznes/master-klass/77212-kak-organizovat-effektivnuyu-rabotu-nad-it-proektom Как организовать эффективную работу над ИТ-проектом] '' |
| | + | </blockquote> |
| | | | |
| | === ИТ и разные подходы к управлению бизнесом === | | === ИТ и разные подходы к управлению бизнесом === |
| − | Граница между большими «готовыми» и «заказными» корпоративными системами не так очевидна, как принято считать. Чтобы убедиться в этом, попробуем для начала разобраться, кто является их покупателем. В этой связи уместно вспомнить два характерных подхода к управлению. | + | Граница между большими «готовыми» и «заказными» корпоративными системами не так очевидна, как принято считать. Чтобы убедиться в этом, попробуем для начала разобраться, кто и для чего их покупает. |
| | | | |
| − | Первый можно условно назвать «консервативным». Как правило, он присутствует в организациях, у которых уровень конкурентного давления не сильно высокий, роль ИТ-инфраструктуры сводится к обеспечению внутренних процедурных задач. Такие компании стремятся минимизировать интеллектуальные расходы на ИТ — зачем изобретать велосипед, если проще его купить. С точки зрения информационных систем это означает, что они предпочитают покупать готовые решения и использовать их практически в неизменном виде. Они не занимаются проектной работой, которая неизбежна в процессе адаптации системы.
| + | В любой компании, независимо от ее размера и сферы деятельности, можно выделить две группы бизнес-процессов. Первую, наиболее многочисленную, составляют обеспечивающие процессы. Сюда относятся процедуры, без которых невозможно нормальное функционирование ни одной компании. Ведение бухгалтерского учета, закупка канцелярских принадлежностей, организация работы базовой ИТ-инфраструктуры — типичные примеры обеспечивающих процессов. Обойтись без них нельзя, однако можно минимизировать затраты на их организацию, например покупая на рынке «лучшие практики». |
| | | | |
| − | Второй подход — «предпринимательский». Практически все отраслевые лидеры и динамично развивающиеся организации в своей работе руководствуются именно им. Они находятся на переднем крае развития отрасли, интеллектуальной мощью их менеджмента создаются корпоративные стандарты, которые через несколько лет станут отраслевыми. А при той скорости, с которой они живут, и с теми объемами информации, которыми они оперируют, невозможно сохранить свои позиции без информационных технологий.
| + | Ко второй группе бизнес-процессов относятся те, что составляют ноу-хау компании и дают ей конкурентное преимущество на рынке. Компания будет всегда стремиться развивать эти бизнес-процессы и повышать их эффективность, чтобы удерживать свои рыночные позиции. И, поскольку речь идет об уникальных процессах, которых нет больше ни у кого, делать это нужно исключительно своими силами, чтобы не потерять преимущества перед конкурентами. |
| | | | |
| − | Очевидно, что все новые подходы ведения бизнеса создаются компанией с целью улучшения своих рыночных позиций и, по сути, являются ее ноу-хау. Поэтому любое ИТ-решение, присутствующее на рынке, сможет удовлетворить потребности организации «предпринимательского» типа в лучшем случае процентов на 80. Для реализации оставшихся 20 процентов запросов систему придется дорабатывать или, как в последнее время часто говорят, — кастомизировать. И компании готовы идти на такой шаг, так как прекрасно понимают, что выгоды от ИТ-проекта с высокой степенью кастомизации несоизмеримо больше затрат на него, хотя объем необходимых в таких проектах инженерных работ очень велик. Дальше речь пойдет о проектах именно такого типа.
| + | Когда речь заходит о выборе ИТ-системы, важно четко представлять, к какой из описанных двух групп относятся процессы, подлежащие автоматизации. Для большинства обеспечивающих процессов лучше всего использовать готовые или коробочные решения, стараясь извлечь максимальную пользу из заложенного в них потенциала. И даже если какие-то из автоматизируемых бизнес-процессов отличаются от тех, что предусмотрены в системе, эффективнее будет перестроить их под готовое ИТ-решение. |
| | + | |
| | + | Для автоматизации процессов, составляющих ноу-хау компании, а также обеспечивающих процессов, изменение которых по разным причинам неприемлемо, любое существующее ИТ-решение придется серьезно дорабатывать, или, как сейчас принято говорить, кастомизировать. И компании готовы идти на такой шаг, поскольку прекрасно понимают, что в данном случае выгоды от ИТ-системы с высокой степенью кастомизации будут несоизмеримо больше затрат на нее. Именно о таких ИТ-решениях мы и будем говорить дальше. |
| | | | |
| | === Уговор дороже денег === | | === Уговор дороже денег === |
| | | | |
| − | Процесс реализации большого проекта с высоким уровнем кастомизации содержит много специфики и сопряжен с рисками. | + | Процесс реализации большого проекта с высоким уровнем кастомизации очень специфичен и сопряжен с рисками. |
| | | | |
| − | Основной риск в том, что заказчик и исполнитель не смогут договориться, что именно надлежит сделать в рамках проекта. Типичная проблема в том, что представители бизнеса формулируют задачу в достаточно общих чертах, мелкие детали их не интересуют. При этом ИТ-инженерия не терпит неопределенностей и требует описания всех необходимых подробностей. | + | Основной риск заключается в том, что заказчик и исполнитель не смогут договориться, что именно надлежит сделать в рамках проекта. Зачастую представители бизнеса формулируют задачу в достаточно общих чертах, мелкие детали их не интересуют. При этом ИТ-инженерия не терпит неопределенностей и требует описания всех необходимых подробностей. |
| | | | |
| − | Наш опыт говорит, что основой успешной реализации проекта будет договоренность о системной архитектуре — верхнем уровне системного проектирования. Речь идет о совместном концептуальном проекте системы — даже для большой системы это документ не более 20-30 страниц, — который понимается одинаково бизнесом заказчика, ИТ-представителями заказчика и исполнителем. Эти рамочные крупноблочные договоренности, которые задают основные степени свободы проекта, и есть системная архитектура проекта. Дальше согласованная системная архитектура становится для трех сторон неоклассическим контрактом, то есть долгосрочным контрактом в условиях неопределенности, когда невозможно заранее предвидеть все последствия заключаемой сделки. И все стороны понимают, что любое отступление от первоначальных договоренностей будет стоить очень дорого, и поэтому относятся к ним в высшей степени ответственно. Представители бизнеса подтверждают, что они заинтересованы в проекте, готовы его финансировать. ИТ-представители и исполнитель, что проект будет реализован в согласованные сроки и бюджет. | + | Наш опыт говорит, что основой успешной реализации проекта является договоренность о системной архитектуре — верхнем уровне ИТ-проектирования. Речь идет о совместном концептуальном проекте системы — даже для большой системы он может быть описан документом не более 20-30 страниц, — который понимается одинаково заказчиком (как со стороны бизнеса, так и со стороны ИТ) и исполнителем. Эти рамочные крупноблочные договоренности, которые задают основные степени свободы проекта, и есть системная архитектура проекта. Дальше согласованная системная архитектура становится для трех сторон неоклассическим контрактом, то есть долгосрочным контрактом в условиях неопределенности, когда невозможно заранее предвидеть все последствия заключаемой сделки. Благодаря этому все стороны понимают, что любое отступление от первоначальных договоренностей будет стоить очень дорого, и относятся к ним в высшей степени ответственно. Представители бизнеса подтверждают, что они заинтересованы в проекте и готовы его финансировать. Представители заказчика со стороны ИТ и исполнитель берут на себя обязательство, что проект будет реализован в оговоренные сроки и в рамках согласованного бюджета. |
| | | | |
| − | Обозначив критическую важность системной архитектуры, поговорим о том, как эффективно получить результат от проекта. | + | Обозначив критическую важность системной архитектуры, поговорим о том, как организовать эффективную работу над проектами с высокой степенью кастомизации. |
| | | | |
| | === В Греции все есть? === | | === В Греции все есть? === |
| | | | |
| − | Согласованная системная архитектура подразумевает, что необходимый инструмент, с помощью которого будет выполняться проект, уже выбран. Иначе ИТ просто не сможет гарантировать, что проект будет сделан. Важно отметить, что вопреки распространенному мнению, любой ИТ-инструмент — достаточно жесткая конструкция. Чем он больше и сложнее, тем больше времени и инженерных работ потребуется для внесения в него требуемых изменений. К примеру, новый завод проще построить на пустом месте, чем строить новый, одновременно ломая старый. Таким образом, правильный выбор инструмента — продукта или платформы уже не столь важно — становится вторым существенным риском. | + | Согласованная системная архитектура подразумевает, что прототип, на базе которого будет выполняться проект, — это может быть и продукт, и платформа — уже выбран. Иначе ИТ просто не сможет гарантировать, что проект будет сделан. Важно отметить, что вопреки распространенному мнению, любой ИТ-материал — достаточно жесткая конструкция. Чем больше и сложнее прототип, тем больше времени и инженерных работ потребуется для внесения в него требуемых изменений. К примеру, новый завод проще построить на пустом месте, чем строить новый, одновременно ломая старый. Таким образом, правильный выбор прототипа становится вторым существенным риском. |
| | | | |
| − | При оценке объемов, а значит и стоимости предстоящих доработок, необходимо учитывать две вещи: требуемый новый функционал и размер инструмента (прототипа). Приведем простой модельный пример. Предположим, что для решения поставленных задач мы можем выбрать из трех прототипов (для простоты A, B и С). У каждого прототипа есть две характеристики: необходимый объем доработок и объем имеющегося в нем функционала. Количественные значения в условных единицах по каждому прототипу представлены в таблице ниже: | + | При оценке объемов, а значит и стоимости предстоящих доработок необходимо учитывать две вещи: размер прототипа и требуемый новый функционал. Приведем простой модельный пример. Предположим, что для решения поставленных задач мы можем выбрать из трех прототипов (для простоты назовем их A, B и С). У каждого прототипа есть две характеристики: объем имеющегося в нем функционала и необходимый объем доработок. Количественные значения в условных единицах представлены в таблице. |
| | | | |
| | {| cellspacing="0" cellpadding="0" border="1" | | {| cellspacing="0" cellpadding="0" border="1" |
| Строка 38: |
Строка 43: |
| | | В | | | В |
| | | С | | | С |
| − | |-
| |
| − | | Объем доработок до желаемой системы (v)
| |
| − | | 300
| |
| − | | 250
| |
| − | | 200
| |
| | |- | | |- |
| | | Объем прототипа (V) | | | Объем прототипа (V) |
| Строка 49: |
Строка 49: |
| | | 1000 | | | 1000 |
| | |- | | |- |
| − | | Итоговая стоимость доработок (условные единицы) | + | | Объем доработок до желаемой системы (v) |
| | + | | 300 |
| | + | | 250 |
| | + | | 200 |
| | + | |- |
| | + | | Итоговая стоимость доработок (у.е.) |
| | | 84 | | | 84 |
| | | 94 | | | 94 |
| Строка 55: |
Строка 60: |
| | |} | | |} |
| | | | |
| − | Итоговая стоимость инженерных работ будет функцией двух значений из каждого столбца следующего вида: (V+v)<sup>n</sup> — V<sup>n</sup>, где 1,5≤ n≤ 2. | + | Итоговая стоимость инженерных работ будет функцией двух значений из каждого столбца следующего вида: (V+v)<sup>n</sup> — V<sup>n</sup>, где 1,5≤ n≤ 2 (в соответствии с моделью оценки стоимости разработки программного обеспечения COCOMO). |
| | | | |
| − | В результате, парадоксальным образом дешевле оказывается вариант А, когда нужно сделать больше изменений на меньшем исходном функционале. Приведенный пример наглядно показывает, что при выборе инструмента, который будет сильно доработан, необходимо учитывать оба параметра — V и v. А истина как всегда где-то посередине: слишком малый прототип — неэффективно дорабатывать, очень большой — тоже неэффективно. | + | В результате парадоксальным образом дешевле оказывается вариант А, когда нужно сделать больше изменений при меньшем исходном функционале. Приведенный пример наглядно показывает, что при выборе ИТ-материала необходимо учитывать оба параметра — размер прототипа и объем доработок. А истина, как всегда, где-то посередине: слишком малый прототип неэффективно дорабатывать, очень большой — тоже неэффективно. |
| | | | |
| | Стоимость разработки одной и той же новой функции в системах с объемами прототипов V и 4V будет соответственно равна 1 у.е. и 3 у.е., а для V и 16V — 1 у.е. и 6 у.е. | | Стоимость разработки одной и той же новой функции в системах с объемами прототипов V и 4V будет соответственно равна 1 у.е. и 3 у.е., а для V и 16V — 1 у.е. и 6 у.е. |
| | | | |
| − | Заметим, что пока мы рассматривали ситуацию в статике. Реально и сама системная архитектура и, значит, объем доработок со временем меняются. Как показывает наша практика, при выборе прототипа более уместен лозунг «Ничего лишнего!», а не традиционный «В Греции все есть» — избыточный функционал придется протаскивать через все доработки. | + | Заметим, что пока мы рассматривали ситуацию в статике. Реально и сама системная архитектура и, значит, объем доработок со временем меняются. Как показывает наша практика, при выборе прототипа более уместен лозунг «Ничего лишнего!», чем традиционный «В Греции все есть», поскольку избыточный функционал придется протаскивать через все доработки. |
| | | | |
| | === Без людей нет идей === | | === Без людей нет идей === |
| | | | |
| − | Третьим существенным риском при внедрении информационной системы с высокой степенью кастомизации оказываются люди, чьими руками будет реализован проект. Успех серьезно зависит от того, насколько персонал, который будет делать инженерные работы, знает инструмент и умеет обращаться с ним. Другими словами — насколько далеко исполнители отстоят от идеологов прототипа системы. Чем ближе они к идеологам и авторам инструмента, тем лучше они умеют им пользоваться и тем скорее они сделают работу эффективно. Чем длиннее цепочка от авторов до внедренцев, тем больше потери знаний к ее концу. В идеале, внедрение системы должны делать авторы. Но так как это не всегда достижимо, авторы, по меньшей мере, должны быть доступны в проекте. Если они вообще не доступны, качество проекта сильно снижается, не говоря о кратном увеличении объема инженерных работ (v). | + | Третьим существенным риском при внедрении информационной системы с высокой степенью кастомизации оказываются люди, чьими руками будет реализован проект. Успех серьезно зависит от того, насколько персонал, который будет делать инженерные работы, знает инструмент и умеет с ним обращаться. Другими словами — насколько далеко исполнители отстоят от идеологов прототипа системы. Чем ближе они к идеологам и авторам инструмента, тем лучше они умеют им пользоваться и тем вероятнее они сделают работу эффективно. Чем длиннее цепочка от авторов до внедренцев, тем больше потери знаний к ее концу. В идеале внедрение системы должны делать авторы. Но так как это не всегда возможно, авторы, по меньшей мере, должны быть доступны в проекте. Если они вообще не доступны, качество проекта сильно снижается, не говоря уже о кратном увеличении объема инженерных работ (v). |
| | | | |
| − | Плюс к этому, названные люди должны быть сильно проектоориентированы. То есть должны уметь уточнять архитектуру, которая хорошо ляжет на инструмент, обеспечит развитие будущей системы в гармонии с бизнесом. Это люди, которым интересны новшества, интересно разбираться в нетривиальных ситуациях.
| + | Кроме того, названные люди должны быть сильно проектоориентированны. То есть должны уметь уточнять архитектуру, которая хорошо «ляжет» на инструмент и обеспечит развитие будущей системы в гармонии с бизнесом. Это люди, которым интересны новшества и нетривиальные задачи. |
| | | | |
| | === Жизнь только начинается === | | === Жизнь только начинается === |
| | | | |
| − | После того, как система внедрена, компания-заказчик рискует стать зависимой от подрядчика в вопросах эксплуатации, сопровождения и, особенно, развития. Поэтому на первый план выходит надежность исполнителя, которая включает два критерия: лояльность и проектная харизма. | + | После того как система внедрена, компания-заказчик рискует стать зависимой от подрядчика в вопросах эксплуатации, сопровождения и — особенно — развития. Поэтому на первый план выходит надежность исполнителя, которую можно охарактеризовать двумя критериями — лояльность и проектная харизма. |
| | | | |
| − | Лояльность понимается в двух аспектах. Во-первых, это готовность исполнителя быстро выполнять специфические требования заказчика. Она существенно зависит от того, предполагает ли подрядчик тиражировать систему. Чем он более заинтересован в тиражировании, тем менее охотно он будет выполнять уникальные разработки, которые в тираж не пойдут. | + | Лояльность понимается в двух аспектах. Во-первых, это готовность исполнителя быстро выполнять специфические требования заказчика. Она существенно зависит от того, предполагает ли подрядчик тиражировать систему. Чем более он заинтересован в тиражировании, тем менее охотно будут выполняться уникальные разработки, которые в тираж не пойдут. |
| | | | |
| − | Во-вторых, это соблюдение ноу-хау бизнеса заказчика, который должен получить гарантии, что специфика его предприятия, организационная структура, бизнес-процессы, корпоративные нормы не станут доступны конкурентам — прочим покупателям системы или услуг того же подрядчика. | + | Во-вторых, это сохранение в тайне ноу-хау бизнеса заказчика, который должен получить гарантии, что сведения о специфике его предприятия, организационной структуре, бизнес-процессах, корпоративных нормах не станут доступны конкурентам — прочим покупателям системы или услуг того же подрядчика. |
| | | | |
| − | Наибольший уровень лояльности у внутреннего IT-отдела. Несколько меньший — у подконтрольных заказчику дочерних компаний. Третий уровень лояльности обеспечивают небольшие компании, специализирующиеся на заказной разработке, которые дают четкие гарантии, что будут работать на интересы клиента. Следующие по убыванию уровни лояльности вообще не заслуживают рассмотрения в контексте статьи, так как ноу-хау не могут быть отданы больше никому. | + | Наибольший уровень лояльности у внутреннего ИТ-отдела предприятия. Несколько меньший — у подконтрольных заказчику дочерних компаний. Третий уровень лояльности обеспечивают небольшие компании, специализирующиеся на заказной разработке, которые дают четкие гарантии, что будут работать на интересы клиента. Следующие по убыванию уровни лояльности вообще не заслуживают рассмотрения в контексте статьи, так как ноу-хау не могут быть отданы больше никому. |
| | | | |
| − | Второй критерий надежности подрядчика — сохранение им проектной харизмы: инновативности, креативности, желания работать на результат. Это характерно именно для небольших проектных компаний. | + | Второй критерий надежности подрядчика — сохранение им проектной харизмы, что предполагает инновативность, креативность, желание работать на результат. Это характерно именно для небольших проектных компаний. |
| | | | |
| | Между лояльностью и проектной харизмой существует обратная зависимость. Наименее лояльный из трех перечисленных уровней сотрудничества (внешняя заказная разработка) на деле весьма востребован, потому что только он в долгосрочной перспективе обеспечивает качественную проектную работу. Причины тому — специализация, невовлеченность в рутинные процессы, постоянное развитие проектных технологий и проектной культуры, работа над промышленным качеством инструментов. В крупных организациях преобладает операционная деятельность, которая затягивает даже проектных людей, и они, скорее всего, уйдут, потеряв перспективы. | | Между лояльностью и проектной харизмой существует обратная зависимость. Наименее лояльный из трех перечисленных уровней сотрудничества (внешняя заказная разработка) на деле весьма востребован, потому что только он в долгосрочной перспективе обеспечивает качественную проектную работу. Причины тому — специализация, невовлеченность в рутинные процессы, постоянное развитие проектных технологий и проектной культуры, работа над промышленным качеством инструментов. В крупных организациях преобладает операционная деятельность, которая затягивает даже проектных людей, и они, скорее всего, уйдут, потеряв перспективы. |
| Строка 87: |
Строка 92: |
| | === В сухом остатке === | | === В сухом остатке === |
| | | | |
| − | Наш опыт работы с информационными системами, требующими высокого уровня кастомизации, позволяет сформулировать следующие основные тезисы. | + | Наш опыт работы с ИТ-системами, требующими высокого уровня кастомизации, позволяет сформулировать следующие основные тезисы. |
| | | | |
| | Качество проекта внедрения и последующих проектов по развитию системы определяется именно качеством инженерной работы. Качество прототипа, который берется за основу, тоже имеет значение, но ничего не гарантирует. Прототип является материалом для инженерной работы, и если она сделана плохо, то никакое самое замечательное качество прототипа ничем не поможет. | | Качество проекта внедрения и последующих проектов по развитию системы определяется именно качеством инженерной работы. Качество прототипа, который берется за основу, тоже имеет значение, но ничего не гарантирует. Прототип является материалом для инженерной работы, и если она сделана плохо, то никакое самое замечательное качество прототипа ничем не поможет. |
| Строка 93: |
Строка 98: |
| | Основной риск таких проектов состоит в том, что будет сделано не то, что нужно. Этот риск снимается правильным отношением всех сторон к системной архитектуре. Надо понимать, что системная архитектура — это согласованные ответственные договоренности бизнеса, его ИТ-структуры и подрядчика, которые, во-первых, понятны бизнесу и, во-вторых, позволяют ИТ-стороне гарантировать реализуемость, сроки и бюджеты. | | Основной риск таких проектов состоит в том, что будет сделано не то, что нужно. Этот риск снимается правильным отношением всех сторон к системной архитектуре. Надо понимать, что системная архитектура — это согласованные ответственные договоренности бизнеса, его ИТ-структуры и подрядчика, которые, во-первых, понятны бизнесу и, во-вторых, позволяют ИТ-стороне гарантировать реализуемость, сроки и бюджеты. |
| | | | |
| − | В проектах оговоренного типа надо тщательно следить за тем, чтобы система была как можно меньшего объема. Любой невостребованный функционал станет серьезным тормозом изменений в системе: чем больше система, тем дороже доработка. Поэтому доктрина «берем как можно больше и кастомизируем» является неэффективной. Эффективный подход — не брать с собой в систему ничего лишнего, а также следить за тем, чтобы в процессе эксплуатации из нее регулярно удалялись рудиментарные функции. | + | В проектах оговоренного типа надо тщательно следить за тем, чтобы система была как можно меньшего объема. Любой невостребованный функционал станет серьезным тормозом для изменений в системе: чем больше система, тем дороже доработка. Поэтому доктрина «берем как можно больше и кастомизируем» является неэффективной. Эффективный подход — не брать с собой в систему ничего лишнего, а также следить за тем, чтобы в процессе эксплуатации из нее регулярно удалялись рудиментарные функции. |
| | | | |
| − | Следующим критическим фактором является удаленность внедренцев от авторов прототипа. Чем они дальше друг от друга, тем хуже качество получаемой системы, и тем больше делается инженерной работы, что негативным образом отражается на сроках и стоимости. | + | Следующим критическим фактором является удаленность внедренцев от авторов прототипа. Чем они дальше друг от друга, тем хуже качество получаемой системы и тем больше объем инженерных работ, что негативным образом отражается на сроках и стоимости. |
| | | | |
| − | Заказчик должен стремиться получить под свой контроль: 100 % эксплуатации, 80 % сопровождения, 20 % развития информационной системы. Это оптимальная ситуация, как с точки зрения рисков, так и с точки зрения затрат на ИТ. Однако, в зависимости от бизнес-приоритетов заказчика, возможны разные варианты. Но всегда на стороне заказчика правильно оставлять два обязательных процесса: 1) контроль над системной архитектурой, который позволяет полностью определять логику своего развития, 2) самостоятельную эксплуатацию всех значимых ИТ-систем, что сильно снижает операционные риски, а также повышает качество внедрений. | + | Заказчик должен стремиться получить под свой контроль 100% эксплуатации, 80% сопровождения и 20% развития ИТ-системы. Это оптимальная ситуация как с точки зрения рисков, так и с точки зрения затрат на ИТ. Однако в зависимости от бизнес-приоритетов заказчика возможны различные варианты. Но всегда на стороне заказчика правильно оставлять два обязательных процесса: 1) контроль над системной архитектурой, который позволяет полностью определять логику развития ИТ-системы; 2) самостоятельную эксплуатацию всех значимых ИТ-систем, что существенно снижает операционные риски, а также повышает качество внедрений. |
| | | | |
| | [[Категория:Владимир Рахтеенко (Статьи)]] | | [[Категория:Владимир Рахтеенко (Статьи)]] |
Текущая версия на 18:06, 14 декабря 2011
«Имейте мужество пользоваться собственным умом»
Иммануил Кант
- Владимир Рахтеенко
- Генеральный директор CUSTIS
В декабре 2011 года эта статья с небольшими сокращениями опубликована на сайте Forbes в рубрике Свой бизнес / Мастер класс
под названием Как организовать эффективную работу над ИТ-проектом
ИТ и разные подходы к управлению бизнесом
Граница между большими «готовыми» и «заказными» корпоративными системами не так очевидна, как принято считать. Чтобы убедиться в этом, попробуем для начала разобраться, кто и для чего их покупает.
В любой компании, независимо от ее размера и сферы деятельности, можно выделить две группы бизнес-процессов. Первую, наиболее многочисленную, составляют обеспечивающие процессы. Сюда относятся процедуры, без которых невозможно нормальное функционирование ни одной компании. Ведение бухгалтерского учета, закупка канцелярских принадлежностей, организация работы базовой ИТ-инфраструктуры — типичные примеры обеспечивающих процессов. Обойтись без них нельзя, однако можно минимизировать затраты на их организацию, например покупая на рынке «лучшие практики».
Ко второй группе бизнес-процессов относятся те, что составляют ноу-хау компании и дают ей конкурентное преимущество на рынке. Компания будет всегда стремиться развивать эти бизнес-процессы и повышать их эффективность, чтобы удерживать свои рыночные позиции. И, поскольку речь идет об уникальных процессах, которых нет больше ни у кого, делать это нужно исключительно своими силами, чтобы не потерять преимущества перед конкурентами.
Когда речь заходит о выборе ИТ-системы, важно четко представлять, к какой из описанных двух групп относятся процессы, подлежащие автоматизации. Для большинства обеспечивающих процессов лучше всего использовать готовые или коробочные решения, стараясь извлечь максимальную пользу из заложенного в них потенциала. И даже если какие-то из автоматизируемых бизнес-процессов отличаются от тех, что предусмотрены в системе, эффективнее будет перестроить их под готовое ИТ-решение.
Для автоматизации процессов, составляющих ноу-хау компании, а также обеспечивающих процессов, изменение которых по разным причинам неприемлемо, любое существующее ИТ-решение придется серьезно дорабатывать, или, как сейчас принято говорить, кастомизировать. И компании готовы идти на такой шаг, поскольку прекрасно понимают, что в данном случае выгоды от ИТ-системы с высокой степенью кастомизации будут несоизмеримо больше затрат на нее. Именно о таких ИТ-решениях мы и будем говорить дальше.
Уговор дороже денег
Процесс реализации большого проекта с высоким уровнем кастомизации очень специфичен и сопряжен с рисками.
Основной риск заключается в том, что заказчик и исполнитель не смогут договориться, что именно надлежит сделать в рамках проекта. Зачастую представители бизнеса формулируют задачу в достаточно общих чертах, мелкие детали их не интересуют. При этом ИТ-инженерия не терпит неопределенностей и требует описания всех необходимых подробностей.
Наш опыт говорит, что основой успешной реализации проекта является договоренность о системной архитектуре — верхнем уровне ИТ-проектирования. Речь идет о совместном концептуальном проекте системы — даже для большой системы он может быть описан документом не более 20-30 страниц, — который понимается одинаково заказчиком (как со стороны бизнеса, так и со стороны ИТ) и исполнителем. Эти рамочные крупноблочные договоренности, которые задают основные степени свободы проекта, и есть системная архитектура проекта. Дальше согласованная системная архитектура становится для трех сторон неоклассическим контрактом, то есть долгосрочным контрактом в условиях неопределенности, когда невозможно заранее предвидеть все последствия заключаемой сделки. Благодаря этому все стороны понимают, что любое отступление от первоначальных договоренностей будет стоить очень дорого, и относятся к ним в высшей степени ответственно. Представители бизнеса подтверждают, что они заинтересованы в проекте и готовы его финансировать. Представители заказчика со стороны ИТ и исполнитель берут на себя обязательство, что проект будет реализован в оговоренные сроки и в рамках согласованного бюджета.
Обозначив критическую важность системной архитектуры, поговорим о том, как организовать эффективную работу над проектами с высокой степенью кастомизации.
В Греции все есть?
Согласованная системная архитектура подразумевает, что прототип, на базе которого будет выполняться проект, — это может быть и продукт, и платформа — уже выбран. Иначе ИТ просто не сможет гарантировать, что проект будет сделан. Важно отметить, что вопреки распространенному мнению, любой ИТ-материал — достаточно жесткая конструкция. Чем больше и сложнее прототип, тем больше времени и инженерных работ потребуется для внесения в него требуемых изменений. К примеру, новый завод проще построить на пустом месте, чем строить новый, одновременно ломая старый. Таким образом, правильный выбор прототипа становится вторым существенным риском.
При оценке объемов, а значит и стоимости предстоящих доработок необходимо учитывать две вещи: размер прототипа и требуемый новый функционал. Приведем простой модельный пример. Предположим, что для решения поставленных задач мы можем выбрать из трех прототипов (для простоты назовем их A, B и С). У каждого прототипа есть две характеристики: объем имеющегося в нем функционала и необходимый объем доработок. Количественные значения в условных единицах представлены в таблице.
|
|
А
|
В
|
С
|
| Объем прототипа (V)
|
200
|
500
|
1000
|
| Объем доработок до желаемой системы (v)
|
300
|
250
|
200
|
| Итоговая стоимость доработок (у.е.)
|
84
|
94
|
100
|
Итоговая стоимость инженерных работ будет функцией двух значений из каждого столбца следующего вида: (V+v)n — Vn, где 1,5≤ n≤ 2 (в соответствии с моделью оценки стоимости разработки программного обеспечения COCOMO).
В результате парадоксальным образом дешевле оказывается вариант А, когда нужно сделать больше изменений при меньшем исходном функционале. Приведенный пример наглядно показывает, что при выборе ИТ-материала необходимо учитывать оба параметра — размер прототипа и объем доработок. А истина, как всегда, где-то посередине: слишком малый прототип неэффективно дорабатывать, очень большой — тоже неэффективно.
Стоимость разработки одной и той же новой функции в системах с объемами прототипов V и 4V будет соответственно равна 1 у.е. и 3 у.е., а для V и 16V — 1 у.е. и 6 у.е.
Заметим, что пока мы рассматривали ситуацию в статике. Реально и сама системная архитектура и, значит, объем доработок со временем меняются. Как показывает наша практика, при выборе прототипа более уместен лозунг «Ничего лишнего!», чем традиционный «В Греции все есть», поскольку избыточный функционал придется протаскивать через все доработки.
Без людей нет идей
Третьим существенным риском при внедрении информационной системы с высокой степенью кастомизации оказываются люди, чьими руками будет реализован проект. Успех серьезно зависит от того, насколько персонал, который будет делать инженерные работы, знает инструмент и умеет с ним обращаться. Другими словами — насколько далеко исполнители отстоят от идеологов прототипа системы. Чем ближе они к идеологам и авторам инструмента, тем лучше они умеют им пользоваться и тем вероятнее они сделают работу эффективно. Чем длиннее цепочка от авторов до внедренцев, тем больше потери знаний к ее концу. В идеале внедрение системы должны делать авторы. Но так как это не всегда возможно, авторы, по меньшей мере, должны быть доступны в проекте. Если они вообще не доступны, качество проекта сильно снижается, не говоря уже о кратном увеличении объема инженерных работ (v).
Кроме того, названные люди должны быть сильно проектоориентированны. То есть должны уметь уточнять архитектуру, которая хорошо «ляжет» на инструмент и обеспечит развитие будущей системы в гармонии с бизнесом. Это люди, которым интересны новшества и нетривиальные задачи.
Жизнь только начинается
После того как система внедрена, компания-заказчик рискует стать зависимой от подрядчика в вопросах эксплуатации, сопровождения и — особенно — развития. Поэтому на первый план выходит надежность исполнителя, которую можно охарактеризовать двумя критериями — лояльность и проектная харизма.
Лояльность понимается в двух аспектах. Во-первых, это готовность исполнителя быстро выполнять специфические требования заказчика. Она существенно зависит от того, предполагает ли подрядчик тиражировать систему. Чем более он заинтересован в тиражировании, тем менее охотно будут выполняться уникальные разработки, которые в тираж не пойдут.
Во-вторых, это сохранение в тайне ноу-хау бизнеса заказчика, который должен получить гарантии, что сведения о специфике его предприятия, организационной структуре, бизнес-процессах, корпоративных нормах не станут доступны конкурентам — прочим покупателям системы или услуг того же подрядчика.
Наибольший уровень лояльности у внутреннего ИТ-отдела предприятия. Несколько меньший — у подконтрольных заказчику дочерних компаний. Третий уровень лояльности обеспечивают небольшие компании, специализирующиеся на заказной разработке, которые дают четкие гарантии, что будут работать на интересы клиента. Следующие по убыванию уровни лояльности вообще не заслуживают рассмотрения в контексте статьи, так как ноу-хау не могут быть отданы больше никому.
Второй критерий надежности подрядчика — сохранение им проектной харизмы, что предполагает инновативность, креативность, желание работать на результат. Это характерно именно для небольших проектных компаний.
Между лояльностью и проектной харизмой существует обратная зависимость. Наименее лояльный из трех перечисленных уровней сотрудничества (внешняя заказная разработка) на деле весьма востребован, потому что только он в долгосрочной перспективе обеспечивает качественную проектную работу. Причины тому — специализация, невовлеченность в рутинные процессы, постоянное развитие проектных технологий и проектной культуры, работа над промышленным качеством инструментов. В крупных организациях преобладает операционная деятельность, которая затягивает даже проектных людей, и они, скорее всего, уйдут, потеряв перспективы.
Снизить зависимость от подрядчика помогает правильное распределение полномочий. Заказчик должен взять на себя контроль над архитектурой, всю эксплуатацию и большую часть сопровождения. Исполнителя правильно освободить от рутины и передать ему большую часть работ по развитию.
В сухом остатке
Наш опыт работы с ИТ-системами, требующими высокого уровня кастомизации, позволяет сформулировать следующие основные тезисы.
Качество проекта внедрения и последующих проектов по развитию системы определяется именно качеством инженерной работы. Качество прототипа, который берется за основу, тоже имеет значение, но ничего не гарантирует. Прототип является материалом для инженерной работы, и если она сделана плохо, то никакое самое замечательное качество прототипа ничем не поможет.
Основной риск таких проектов состоит в том, что будет сделано не то, что нужно. Этот риск снимается правильным отношением всех сторон к системной архитектуре. Надо понимать, что системная архитектура — это согласованные ответственные договоренности бизнеса, его ИТ-структуры и подрядчика, которые, во-первых, понятны бизнесу и, во-вторых, позволяют ИТ-стороне гарантировать реализуемость, сроки и бюджеты.
В проектах оговоренного типа надо тщательно следить за тем, чтобы система была как можно меньшего объема. Любой невостребованный функционал станет серьезным тормозом для изменений в системе: чем больше система, тем дороже доработка. Поэтому доктрина «берем как можно больше и кастомизируем» является неэффективной. Эффективный подход — не брать с собой в систему ничего лишнего, а также следить за тем, чтобы в процессе эксплуатации из нее регулярно удалялись рудиментарные функции.
Следующим критическим фактором является удаленность внедренцев от авторов прототипа. Чем они дальше друг от друга, тем хуже качество получаемой системы и тем больше объем инженерных работ, что негативным образом отражается на сроках и стоимости.
Заказчик должен стремиться получить под свой контроль 100% эксплуатации, 80% сопровождения и 20% развития ИТ-системы. Это оптимальная ситуация как с точки зрения рисков, так и с точки зрения затрат на ИТ. Однако в зависимости от бизнес-приоритетов заказчика возможны различные варианты. Но всегда на стороне заказчика правильно оставлять два обязательных процесса: 1) контроль над системной архитектурой, который позволяет полностью определять логику развития ИТ-системы; 2) самостоятельную эксплуатацию всех значимых ИТ-систем, что существенно снижает операционные риски, а также повышает качество внедрений.
Репликация: База Знаний «Заказных Информ Систем» → «Имейте мужество пользоваться собственным умом, или Как организовать эффективную работу над ИТ-проектом»
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
|
 |
