Советы гендиректора компании CUSTIS (разработка ИТ-систем).

Оптимальная ситуация – когда заказчик стремиться контролировать 100% эксплуатации, 80% сопровождения и 20% развития ИТ-системы.

«Заказные» и «готовые» корпоративные системы не так очевидно друг от друга отличаются, как принято считать. Для начала мы попробуем выяснить, кто их покупает и для чего.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Опираясь на наш опыт по работе с ИТ-системами, которым нужен высокий уровень кастомизации, мы сформулировали основные тезисы:

• Главный риск такого проекта в том, что может быть сделано не то, что было нужно. Этот риск можно снять с помощью правильного отношения всех сторон к системной архитектуре проекта. Системная архитектура – это все ответственные договоренности, согласованные между предприятием, его ИТ-структурой и подрядчиком, которые понятны предприятию и позволяют ИТ-стороне дать гарантии реализуемости, сроков и бюджетов.
• В оговоренных проектах нужно внимательно следить за минимизацией объема системы. Каждый ненужный функционал будет серьезно тормозить внесение изменений в систему: чем большей будет система, тем больше придется заплатить за доработку.
• Еще один критический фактор – удаленность команды внедрения от авторов прототипа. Чем больше расстояние между ними, тем хуже качество конечного результата и тем больше объем требующихся инженерных работ, а это негативно отразится на сроках и цене проекта.
• Заказчику нужно постараться заполучить контроль над 100% эксплуатации, 80% сопровождения и 20% развития системы. Практика показывает, что это оптимальный вариант как для снижения рисков, так и для уменьшения расходов на ИТ.