От поиска ИТ-решения к внедрению

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

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

Анализ ситуации

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

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

Здесь условно можно выделить четыре области:

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

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

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

Поиск и выбор решения

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

В области 1 можно быстро собрать большой список возможных кандидатов, открыто объявить требования и выбрать минимальную стоимость покупки, которая здесь является единственным критерием. В областях 2, 3 вас ждет либо короткий поиск единственного безальтернативного поставщика, либо долгое осознание своих требований и выбор того, кто их может обеспечить. Круг претендентов в обоих случаях довольно узок. В области 2 потому, что продукт может производиться немногими, а в области 3 — потому что не понимая собственных требований, нет смысла объявлять об этом внешнему миру. Поскольку участников мало, то наиболее эффективный способ выбора — закрытый анализ предложений. В области 4 вас ожидает длительный итеративный процесс. Итерации в осознании собственных требований порождают как итерации в отношениях с возможными поставщиками, так и итерации в будущей разработке. Все уже хорошо усвоили, что проекты в стиле «водопада» в ИТ-индустрии не работают. Так почему же должен работать линейный поиск и выбор ИТ-решения и его поставщика? Вы действительно начинаете понимать, чего хотите, по ходу разработки и детализации требований, и это нормально. Гарантированно, что по ходу будут меняться не только требования, но и состав вовлеченных участников, а также условия взаимоотношений с ними. Если двигаться не итерациями, то легко можно угодить в череду конфликтов. Значит, надо учиться этими ожиданиями управлять. Лучше это делать итеративно, шаг за шагом проявляя и детализируя ожидания всех заинтересованных сторон.

Монетизация неопределенности

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

Качество — это получаемая человеком ценность в любой форме.

Продукт — это контракт, сочетающий в себе покупку произведенного товара и сервиса по его будущей под­держке.

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

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

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

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

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

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

Борьба за «хороший» контракт

Одним из важных моментов при выборе ИТ-решения является готовность поставщика работать по удобному для вас контракту. Задумайтесь, а есть ли у вас хороший шаблон контракта, который вы могли бы предложить будущему поставщику ИТ-решения? Наиболее эффективный способ — заранее разработать типовой модульный контракт и прикладывать его в качестве приложения к списку стартовых требований при выборе ИТ — решения (Request for Proposals — RfP). Но даже если у вас есть такой шаблон, сможете ли вы навязать использование контракта слово в слово? Здесь всё зависит от того, насколько сильны заказчик и поставщик. Под силой обобщенно можно понимать уровень зрелости, масштаб бизнеса и сложность управления. Стандартизация процессов, регламентов и процедур, контрактов является следствием этой зрелости компании.

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

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

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

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

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

В нём условно можно выделить четыре области:

1) область поиска компромиссов после выбора. Поскольку обе стороны не имеют жестких регламентов и контрактов, выбор все равно происходит, но его детали проявляются уже после, на стадии согласования контракта юристами с обеих сторон;

2 и 3) области навязывания своего шаблона контракта. Крайние случаи такого навязывания — это типовой контракт для розничного массового клиента либо небольшой заказ со стороны крупной компании у мелкого производителя. В такой ситуации одна из сторон предлагает заключить контракт, из которого нельзя выкинуть ни одного слова, ссылаясь, например, на свой бренд и заявляя, что любая правка либо невозможна, либо потребует громадного согласования внутри компании;

4) область согласования бизнес-принципов. От области 1 принципиально отличается степенью зрелости, масштабом и сложностью управления процессом с обеих сторон. Можно сколько угодно навязывать свой текст контракта, но окончательный вариант все равно будет отличаться от обоих текстов. Чтобы это не тормозило процесс выбора, можно эффективно действовать в две итерации. До выбора решения можно включить раздел «Основные бизнес-принципы» в качестве обязательных требований. Это значительно сузит неопределенность. А после выбора, с учетом уже согласованных ограничений, сверить и согласовать более мелкие расхождения в текстах контрактов.

Определение точки перехода

Жизненный цикл программного продукта делится как ми­­нимум на две фазы — внедрение и развитие. Со­­ответственно стоимость владения ИТ-продуктом (TCO) делится на две части — стоимость внедрения и стоимость развития. Развитие системы, в свою очередь, разделяется на стандартую поддержку и доработку.

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

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

Для определения точки окончания проекта можно предложить очень простой способ — список стартовых требований при поиске (Request for Information — RfI) и при выборе (RfP) разбивать не на две, как это принято, а на четыре части:

• важные известные обязательные требования. Без их выполнения найденный продукт не подлежит внедрению;
• неважные известные детальные требования. Продукт, выполняющий эти требования, можно включить в выбор, и стоимость данных требований может быть оценена по фиксированной цене;
• неважные известные, но не проявленные требования. Это самая тонкая область. Продукт, выполняющий данные требования, можно включить в выбор, но реализация детальных требований может потребовать доработки. С позиций заказчика такие доработки лучше включать в проект с фиксированной ценой, но их практически невозможно проверить на стадии выбора продукта. Иными словами, они являются частью RfP, влияют на стоимость, но не могут быть предметом тестирования на стадии стендовых испытаний или пилотного проекта;
• неизвестные и непроявленные требования. Они не могут быть включены в RfP и в проект внедрения, поскольку пока неизвестны. Их стоимость может оцениваться по количеству человеко-дней, затрачиваемых на доработки, которое заранее неизвестно.

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

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