Автор - гендиректор компании CUSTIS, занимающейся разработкой ИТ-систем
Граница между «готовыми» и «заказными» корпоративными системами не так очевидна, как принято считать. Чтобы убедиться в этом, попробуем для начала разобраться, кто и для чего их покупает.
В любой компании, независимо от ее размера и сферы деятельности, можно выделить две группы бизнес-процессов. Первую, наиболее многочисленную, составляют обеспечивающие процессы. Сюда относятся процедуры, без которых невозможно нормальное функционирование компании: ведение бухгалтерского учета, закупка канцелярских принадлежностей, организация работы базовой ИТ-инфраструктуры. Обойтись без них нельзя, однако можно минимизировать затраты на их организацию, например покупая на рынке «лучшие практики».
Ко второй группе бизнес-процессов относятся те, что составляют ноу-хау компании и дают ей конкурентное преимущество на рынке. И, поскольку речь идет об уникальных процессах, которых нет больше ни у кого, делать это нужно исключительно своими силами.
Для автоматизации процессов, составляющих ноу-хау компании, а также обеспечивающих процессов, изменение которых по разным причинам неприемлемо, любое существующее ИТ-решение придется серьезно дорабатывать, или, как сейчас принято говорить, кастомизировать. И компании готовы идти на такой шаг, поскольку прекрасно понимают, что в данном случае выгоды от ИТ-системы с высокой степенью кастомизации будут несоизмеримо больше затрат на нее. Именно о таких ИТ-решениях мы и будем говорить дальше.
Уговор дороже денег
Процесс реализации большого проекта с высоким уровнем кастомизации очень специфичен и сопряжен с рисками. Основной риск заключается в том, что заказчик и исполнитель не смогут договориться, что именно надлежит сделать в рамках проекта. Зачастую представители бизнеса формулируют задачу в достаточно общих чертах, мелкие детали их не интересуют. При этом ИТ-инженерия не терпит неопределенностей и требует описания всех необходимых подробностей.
Наш опыт говорит, что основой успешной реализации проекта является договоренность о системной архитектуре — верхнем уровне ИТ-проектирования. Речь идет о совместном концептуальном проекте системы — даже для большой системы он может быть описан документом не более 20–30 страниц — который понимается одинаково заказчиком (как со стороны бизнеса, так и со стороны ИТ) и исполнителем. Эти рамочные договоренности, которые задают основные степени свободы проекта, и есть системная архитектура проекта. Дальше согласованная системная архитектура становится для трех сторон неоклассическим контрактом, то есть долгосрочным контрактом в условиях неопределенности, когда невозможно заранее предвидеть все последствия заключаемой сделки.
Обозначив критическую важность системной архитектуры, поговорим о том, как организовать эффективную работу над проектами с высокой степенью кастомизации.
В Греции все есть?
Согласованная системная архитектура подразумевает, что прототип, на базе которого будет выполняться проект (это может быть и продукт, и платформа), уже выбран. Иначе ИТ просто не сможет гарантировать, что проект будет сделан. Чем больше и сложнее прототип, тем больше времени и инженерных работ потребуется для внесения в него требуемых изменений. К примеру, новый завод проще построить на пустом месте, чем строить новый, одновременно ломая старый. Таким образом, правильный выбор прототипа становится вторым существенным риском.
При оценке объемов, а значит, и стоимости предстоящих доработок необходимо учитывать две вещи: размер прототипа и требуемый новый функционал. Часто парадоксальным образом дешевле оказывается вариант, когда нужно сделать больше изменений при меньшем исходном функционале. В любом случае слишком малый или слишком большой прототип дорабатывать неэффективно.
Заметим, что пока мы рассматривали ситуацию в статике. В реальности же и сама системная архитектура, и объем доработок со временем меняются. Как показывает наша практика, при выборе прототипа более уместен лозунг «Ничего лишнего!», чем традиционный «В Греции все есть!», поскольку избыточный функционал придется «протаскивать» через все доработки.
Без людей нет идей
Третьим существенным риском при внедрении информационной системы с высокой степенью кастомизации оказываются люди, чьими руками будет реализован проект. Успех серьезно зависит от того, насколько персонал, который будет делать инженерные работы, знает инструмент и умеет с ним обращаться. Чем длиннее цепочка от авторов до внедренцев, тем больше потери знаний к ее концу.
Кроме того, люди должны быть сильно проектоориентированны. Подразумевается, что они умеют создавать архитектуру, которая хорошо «ляжет» на инструмент и обеспечит развитие будущей системы в гармонии с бизнесом. Это люди, которым интересны новшества и нетривиальные задачи.
Жизнь только начинается
После того как система внедрена, компания-заказчик рискует стать зависимой от подрядчика в вопросах эксплуатации, сопровождения и особенно развития. Поэтому на первый план выходит надежность исполнителя, которую можно охарактеризовать двумя критериями — лояльность и проектная харизма.
Лояльность понимается в двух аспектах. Во-первых, это готовность исполнителя быстро выполнять специфические требования заказчика. Она существенно зависит от того, предполагает ли подрядчик тиражировать систему. Чем более он заинтересован в тиражировании, тем менее охотно будут выполняться уникальные разработки, которые в тираж не пойдут.
Во-вторых, это сохранение в тайне ноу-хау бизнеса заказчика, который должен получить гарантии, что сведения о специфике его предприятия, организационной структуре, бизнес-процессах, корпоративных нормах не станут доступны конкурентам — прочим покупателям системы или услуг того же подрядчика.
Наибольший уровень лояльности у внутреннего ИТ-отдела предприятия. Несколько меньший — у подконтрольных заказчику дочерних компаний. Третий уровень лояльности обеспечивают небольшие компании, специализирующиеся на заказной разработке, которые дают четкие гарантии, что будут работать на интересы клиента.
Второй критерий надежности подрядчика — сохранение им проектной харизмы, что предполагает креативность и желание работать на результат. Между лояльностью и проектной харизмой существует обратная зависимость. Наименее лояльный из трех перечисленных уровней сотрудничества (внешняя заказная разработка) на деле весьма востребован, потому что только он в долгосрочной перспективе обеспечивает качественную проектную работу. Причины тому — специализация, невовлеченность в рутинные процессы, постоянное развитие проектных технологий и проектной культуры, работа над промышленным качеством инструментов. В крупных организациях преобладает операционная деятельность, которая затягивает даже проектных людей, и они, скорее всего, уйдут, потеряв перспективы.
Снизить зависимость от подрядчика помогает правильное распределение полномочий. Заказчик должен взять на себя контроль над архитектурой, всю эксплуатацию и большую часть сопровождения. Исполнителя правильно освободить от рутины и передать ему большую часть работ по развитию.
В сухом остатке
Наш опыт работы с ИТ-системами, требующими высокого уровня кастомизации, позволяет сформулировать следующие основные тезисы.
— Основной риск таких проектов состоит в том, что будет сделано не то, что нужно. Этот риск снимается правильным отношением всех сторон к системной архитектуре. Надо понимать, что системная архитектура — это согласованные ответственные договоренности бизнеса, его ИТ-структуры и подрядчика, которые, во-первых, понятны бизнесу и, во-вторых, позволяют ИТ-стороне гарантировать реализуемость, сроки и бюджеты.
— В проектах оговоренного типа надо тщательно следить за тем, чтобы система была как можно меньшего объема. Любой невостребованный функционал станет серьезным тормозом для изменений в системе: чем больше система, тем дороже доработка.
— Следующим критическим фактором является удаленность внедренцев от авторов прототипа. Чем они дальше друг от друга, тем хуже качество получаемой системы и тем больше объем инженерных работ, что негативным образом отражается на сроках и стоимости.
— Заказчик должен стремиться получить под свой контроль 100% эксплуатации, 80% сопровождения и 20% развития ИТ-системы. Как показывает наш опыт, это оптимальная ситуация как с точки зрения рисков, так и с точки зрения затрат на ИТ.