Когда к вам едет ревизор, это не всегда плохо, а часто просто жизненно необходимо. Особенно если предстоит выполнить сложный ИТ-проект, такой как внедрение хранилища данных. И речь идет о предпроектном обследовании.
Я работаю в компании GlowByte, а в целом в ИТ – более 20 лет. В последние годы в основном занимаюсь проектами и решениями в области AI, аналитики, больших данных, но приходилось иметь дело с большим списком разнообразных ИТ-услуг и форм взаимодействия заказчиков и подрядчиков. По роду деятельности мне приходится много заниматься подготовкой, оценкой, запуском ИТ-проектов. Очень часто нормально проведенное предпроектное обследование становится залогом успешного проекта, поэтому решил, что мои мысли про предпроект, его цели и подводные камни могут быть интересны аудитории.
Представим ситуацию: крупная компания планирует построить хранилище данных или мигрировать имеющееся ХД на другую платформу и собирается провести тендер по выбору подрядчика на проект. Компания стартует конкурс или, для начала, запрашивает информацию для оценки рынка. Направляет запрос потенциальным подрядчикам. В нем, конечно, куча разных стандартных документов о том, как будет проводиться закупка, как компания борется с коррупцией, драфт договора и пр., но есть и ТЗ – зачастую единственный сутевой документ, из которого подрядчики должны понять, что нужно делать, и на основании которого будут оценивать проект. И вот потенциальные подрядчики получают такое ТЗ – просто несколько листов в текстовом формате.
Или наоборот, подрядчики получают Excel-таблицу с десятком вкладок, в каждой из которых несколько сот пунктов с требованиями. Но когда начинаешь читать, понимаешь, что все эти “пожелания” были собраны сотрудниками десятка разных отделов и механически “склеены” в один документ. Требования приведены общим списком на совершенно разных уровнях абстракции (радом могут быть требования типа “необходимо реализовать ежедневный расчет показателя Х в разрезе Y в отчете Z” и “система должна поддерживать загрузку данных из СУБД A, B и C”). Многие из них противоречат друг другу. Основные требования либо зарыты глубоко под ворохом второстепенных, либо о них вообще позабыли. В общем, понять, что же на самом деле требуется, так же сложно, как и когда в требованиях не написано почти ничего.
Да, основная идея того, что требуется, обычно все же описана. Но можно ли из таких ТЗ сделать однозначный вывод о составе необходимых работ, ожидаемых результатах, предпочтительном технологическом стеке и тем более о том, какие инструменты интеграции предпочтительно использовать для таких-то потоков данных? Что из предоставленного ТЗ можно понять про текущую ситуацию, имеющиеся ограничения или пожелания к реализации?
Даже имея большой опыт в данной предметной области и именно в такого рода проектах, зачастую из тендерного задания можно извлечь лишь крохи полезной информации. Подрядчики как-то оценивают проект, получается большой разброс цен. Вместо того, чтобы задуматься о том, насколько хорошо и детально подрядчики поняли задачу, служба закупок выбирает победителя, соответствующего формальным критериям и предложившего наименьшую цену.
Если подрядчик, основываясь на своем видении того, что он будет делать, мелким шрифтом написал в своем КП кучу ограничений и условий, тогда заказчик вскоре неожиданно обнаружит, что нарисованные в его воображении космические замки вряд ли обретут реальность, по крайней мере, в рамках выделенного бюджета.
Чаще бывает наоборот: заказчик настаивает на том, что подрядчик, принимающий участие в тендере, по умолчанию должен полностью, без оговорок, согласиться с ТЗ. В этом случае все, что там “подразумевалось”, становится таким обременением проекта, что либо подрядчик уйдет по маржинальности “в жесткий минус”, либо, если он с таким поворотом окажется несогласен, между сторонами проекта будут возникать постоянные разногласия и споры, которые добавят стресса и седых волос всем участникам.
А ведь такой ситуации можно избежать. Нужно лишь до старта проекта проработать задачу на таком уровне детальности, чтобы подрядчик и заказчик могли понять, что и как будет сделано. Единое понимание результатов минимизирует риск неоправданных ожиданий с обеих сторон. Конечно, почва для недопониманий всегда остается, но предпроект позволяет свести факторы к разумному минимуму за счет формирования структурированного и детального ТЗ, включающего требуемый набор артефактов, соответствующих целям и задачам проекта.
Проекты по обследованию могут быть полезны перед внедрением практически для любых систем и решений, которые имеют достаточно высокую стоимость (десятки миллионов рублей) и большой срок реализации (от 6 месяцев и более). При рассказе о подходах к обследованию я буду использовать пример внедрения корпоративного хранилища данных. Он достаточно универсален, прост и понятен для большинства читателей – по крайней мере, по сравнению с перекладкой отчетности по IFRS или внедрением PLM-решения. Но обсуждаемые в статье вопросы в большинстве случаев актуальны и для обследований перед проектами в совершенно иных областях.
Отдельный предпроект или этап проекта?
Обследование можно проводить как отдельный проект, по отдельному договору. А можно сделать первым этапом собственно проекта внедрения, так называемым этапом проектирования. Есть ли разница?
Предпроект, который делается по отдельному договору, а не как этап проекта, имеет целью сформировать требования к проекту, определить сроки, бюджет и пр. Если необходимо, то ставится и задача подготовить обоснование затрат на проект перед акционерами. В этом варианте подразумевается, что все эти необходимые для запуска проекта параметры заказчик самостоятельно подготовил лишь на самом общем уровне – таком, который не позволяет даже открыть проект и более-менее детально спланировать его реализацию.
Если же заказчик своими силами собрал требования, проанализировал рынок, пообщался с вендорами и подрядчиками, провел встречи с коллегами по цеху и по результатам сумел хотя бы примерно осметить проект, оценить сроки, потребности в ресурсах, предпочтительные варианты техстека и т. п., то он может запустить проект в рамках согласованного бюджета и первый его этап посвятить уже углубленному обследованию – с целью уточнить ранее собранные требования, разработать ТЗ и детально спроектировать будущую систему.
Таким образом, то, как организовать предпроект – отдельно или в составе самого проекта – зависит от готовности заказчика взять на себя проработку и защиту проекта до его запуска. Главное – не перепутать варианты и выбрать правильный. Ведь кейсы, когда заказчик, собрав несколько страниц самых верхнеуровневых требований и заложив в бюджет самую низкую оценку из полученных с рынка ответов, сразу выходит на тендер, – не редкость. В таких случаях он либо вообще не получает релевантных предложений, либо получает их с таким количеством оговорок и ограничений, что это делает предстоящий проект крайне рискованным с точки зрения достижения поставленных целей. А ведь отдельное обследование до запуска тендера могло бы решить эту проблему и существенно сократить в том числе персональные риски на стороне заказчика.
Цели предпроекта. Обследование обследованию рознь
Прежде чем решить, какие требования предъявлять подрядчику по обследованию (а после – и выбирать его самого), нужно определить цель мероприятия – для чего вам нужен этот предпроект. Для многих обследование – это всегда просто уточнение требований к проекту и подготовка необходимой для старта проекта документации. Но на практике есть нюансы, которые существенно влияют на состав задач и объем работ.
Например, обследование может проводится с целью принятия решения о запуске проекта или – классический вариант – для подготовки тендерной документации. Или же для получения исчерпывающего и максимально подробного набора документов для последующей самостоятельной реализации проекта заказчиком. Есть еще и четвертый вариант, который встречается не так уж и редко, – когда на стороне заказчика нет консенсуса, как делать проект. Разные мнения касаются выбора архитектуры, технологического стека, приоритетов реализации задач и т. п. В такой ситуации именно внешний аудитор может помочь, если, конечно, ему доверяют все стороны.
От цели сильно зависит скоуп обследования, а значит – необходимые для его выполнения ресурсы, сроки и цена. Я бы не стал рекомендовать ни урезать требования к результатам, потому что хочется сэкономить, ни раздувать их, потому что хочется получить всю возможную информацию по максимуму. Запрашиваемый состав и уровень детальности результирующих документов должен соответствовать стоящей перед заказчиком цели. Тогда не случится ни разочарования, что вместо ожидаемых 500 страниц подрядчик выдал презентацию на 20 слайдов, ни переплаты, когда миллионы рублей тратятся на никому не нужные красивые бумажки. Ведь обследование не проводится впрок. Уже через год, а то и раньше его результаты, если ими не воспользоваться сразу, можно будет смело пустить в шредер. Процессы, системы, технологии сегодня так быстро меняются, что есть смысл проводить аудит только непосредственно перед тем, как планируете использовать его выходные документы для запуска и реализации проекта.
Что на выходе? Ожидания и реальность
Чтобы проект по обследованию не превратился в локальные военные действия между заказчиком и подрядчиком, хорошо бы еще до его старта определиться с ожидаемыми результатами и приложить усилия к тому, чтобы убедиться в едином понимании этих результатов у обеих сторон. Нормальный срок для полномасштабного предпроекта – это два-три месяца. Но бывает, и не так уж редко, что такие проекты затягиваются на год. Очевидно, что довольных при таком раскладе просто не бывает. Кто-то не получит премию, и все потеряют много нервных клеток.
Как писал выше, первый приоритет – правильно сформулировать цели: зачем нужен этот аудит. Затем уже, понимая зачем, нужно решить, что именно должно получиться на выходе. А если подберете правильного подрядчика, то он, опираясь на свой опыт, расскажет, как реализовать запрашиваемый результат, сколько времени на этой уйдет, сколько это будет стоить, какие есть подводные камни и как наилучшим образом их обойти.
Посмотрим, какие результаты стоит ожидать для вариантов обследования под разные цели.
Вариант 1.
Если нужно подготовить необходимые аргументы для принятия высшим руководством решения о запуске проекта, то результатом, как правило, должна быть не длинная, но очень аргументированная презентация. Объем такой презентации может варьироваться от масштаба проекта, но вряд ли разумно требовать больше 25-30 слайдов. Для распорядителей бюджета порой и нескольких слайдов достаточно, потому что люди они крайне занятые и при принятии решения часто негативно воспринимают попытку погрузить их во все детали.
В презентации стоит показать текущий ландшафт предполагаемой для изменения области, причины, которые вызывают необходимость внедрения новой системы (предпосылки внедрения), описать целевое состояние, которое должно наступить в случае успешной реализации проекта, примерно оценить его стоимость – например, на основании имеющихся бенчмарков показать, как предлагаемые изменения позволят окупить затраты или хотя бы улучшить работу организации.
Сложные календарные планы, списки потенциальных проектных рисков, длинные и подробные сметы, детальные архитектурные схемы в такой презентации будут бесполезны, а скорее даже вредны. На реальную проработку таких данных либо придется впустую потратить кучу времени, либо они будут настолько неточны, что окажутся практически лишенными смысла.
Тем не менее заказчики настаивают на том, чтобы все это было проработано, включено в презентацию, которая в итоге раздувается до сотни слайдов и больше. Почему это происходит? Во многом из-за неверного понимания цели предпроекта и попытки сделать задел на будущее: “Вот убедим руководство, что проект нужно запускать, а у нас уже будут сразу ответы на все вопросы и все нужные артефакты для его запуска”. На практике же толку от таких подготовленных нецелевым образом десятков слайдов будет не больше, чем от просмотра на досуге вендорских презентаций – только лишнее время потратите на подготовку и согласование этой опциональной в данном случае информации. Все потом придется переделать, поэтому лучше сделать короткую, но соответствующую цели обследования презентацию.
Вариант 2.
Когда цель обследования – подготовка всех необходимых документов проведения тендера для выбора решения и подрядчика, то тут короткой презентацией явно не обойтись. Чтобы сначала сравнить “яблоки с яблоками”, а потом внедрить то, что ожидается, нужно подготовить несколько обязательных артефактов:
Собрать достаточно детальные требования, как функциональные, так и нефункциональные (требования к ИБ, производительности, отказоустойчивости и пр.).
Проработать архитектуру решения и технологический стек. Понятно, что архитектура обязательно будет уточняться уже в ходе проекта, но если ее не проработать в ходе обследования, то высоки риски, что потребуется “перевнедрение” уже через два-три года, а ведь проекты типа КХД рассчитаны на эксплуатацию без серьезных изменений лет десять, не меньше. В предпроекте совсем не обязательно определяться с решениями конкретных вендоров или версиями опенсорс-компонент. Но когда понятна целевая архитектура, гораздо проще определиться с потенциальными ее поставщиками и интеграторами.
Рассчитать сайзинг необходимого оборудования. Железо в таких ресурсоемких проектах, как DWH, составляет значительную часть проектной стоимости, особенно с учетом его подорожания в последние годы. Даже если предполагается развертывание в облаке и сама закупка “железа” не потребуется, все равно оценить стоимость подписки требуется, это значимый блок затрат. Опять же стоит не забывать про все среды, DR-ы и прочие моменты, которые иногда преподносят сюрпризы на десятки миллионов в самый неожиданный момент, перед запуском проекта в прод.
Определиться со сметой проекта и ТСО на срок три-пять лет. Включить в смету не только работы по реализации проекта, но и стоимость лицензий на ПО, если предполагается внедрять не чисто опенсорс, стоимость оборудования (закупки, аренды, подписки на сервисы), вендорской техподдержки и расширенной поддержки от интегратора, работ по обучению, а, возможно, и консалтинга по построению центра компетенций у заказчика, включая подбор нужных специалистов, выстраивание процессов.
Сформировать примерный, но детализированный календарный план проекта и его дорожную карту. Детальный план полезен, потому что позволяет не только понять, когда будут достигнуты значимые для проекта вехи (например, запуск первой очереди потоков данных в ОПЭ), но и определить когда и какие ресурсы потребуются от самого заказчика. А ведь иногда из-за отсутствия нужных доступов или задержки в поставке серверов срок проекта сдвигается на месяцы просто потому, что заранее эта потребность не была зафиксирована в плане. Дорожная карта же строится на более длительный срок (до двух-трех лет) и позволяет определиться с последовательностью реализации больших этапов развития проекта с учетом приоритетов бизнеса, технологических и финансовых возможностей заказчика. Например, в дорожной карте стоит выстроить последовательность подключения систем-источников, порядок включения в проект бизнес-доменов (финансы, закупки, бухгалтерия, продажи, логистика и пр.), а также сроки подключения к проекту обособленных подразделений или компаний холдинга в рамках расширения организационного скоупа проекта.
Оценить рынок решений, соответствующих выбранной архитектуре платформ: какие вендоры или опенсорс-продукты есть на рынке, кто и где их внедрял, с каким результатом. Возможно, даже выяснить или оценить примерные затраты (хотя вся эта информация обычно под NDA, но зачастую какие-то цифры можно достать в том или ином виде). Конечно, вендор-селекшн – это отдельный класс проектов, и не стоит смешивать его с предпроектным обследованием, но собрать и структурировать информацию о рынке требуемых решений в рамках обследования вполне возможно и даже полезно.
Вариант 3.
Если задача у заказчика – внедрить DWH своими силами, то требования к результатам обследования будут отличаться от приведенных в вариантах один и два. Хотя пересечения есть. Презентация для руководства с целью обоснования проекта внедрения КХД потребуется, но фокус в ней должен быть на обосновании реализации собственными силами, преимуществах создания центра компетенции, перспективности предлагаемой архитектуры и функционального наполнения для решения задач бизнеса. Также обычно просят сделать упор на проработку состава и квалификации внутренней проектной команды, необходимость вовлечения бизнеса и выстраивания процессов взаимодействия Центра компетенции с пользователями. Часто требуется более детально, чем в версии для подготовки тендера, поработать с системами-источниками, провести профилирование данных, спроектировать не только архитектуру ХД, но и проработать модель данных, подготовить требования по проверкам качества данных и пр.
Резюмируя данный раздел, можно еще раз подчеркнуть, что нет смысла копировать требования к результатам предпроекта из лучших практик или из другого аудита, который компания проводила для других целей. Нужно в первую очередь понять цель, а уже потом под нее согласовать тот набор артефактов с нужной степенью детальности, который требуется для достижения именно этой цели. В любом случае, максимально точно зафиксированный состав ожидаемых от проекта результатов работ позволит уменьшить риски недовольства сторон друг другом и затягивания сроков.
“Мы сами”. Что мешает сделать обследование своими силами?
Можно ли провести обследование для реализации проекта внедрения DWH своими силами, не привлекая никаких подрядчиков? Этот вопрос у заказчика возникает почти всегда. Ведь у руководства компании зачастую складывается впечатление, что раз ситуация под контролем, значит, соответствующее подразделение (ИТ) хорошо понимает текущий ландшафт, отслеживает развитие технологий, знает потребности бизнеса, понимает, как управлять сложными проектами. Да и не такой уж масштабный проект это обследование. Не чета собственно проекту внедрения. Поэтому топ-менеджерам кажется, что сотрудники способны самостоятельно справиться с подготовкой всех необходимых для подготовки проекта артефактов.
Отдельный бюджет на обследование в таком случае выделять не нужно. На первый взгляд, одна только польза и прямая экономия. В реальности проведение обследования силами заказчика – вполне выполнимая задача, но для этого требуется решить несколько вопросов. В противном случае время будет потрачено, а результат окажется таким, что от него может быть больше вреда, чем экономии.
Что стоит предусмотреть для выполнения предпроекта своими силами:
Наличие специалистов нужной квалификации. Если у заказчика пока не реализовано ХД или же оно построено на устаревшем стеке, то совершенно не факт, что в компании есть нужные специалисты, владеющие актуальными технологиями и процессами, которые с большой долей вероятности будут выбраны для внедрения. Если под будущий проект заказчик сможет взять несколько специалистов с профильным опытом и хорошими технологическими навыками, то задача существенно упрощается. Понятно, что, чтобы взять таких специалистов, потребуется бюджет, который в любом случае придется найти и выделить. Как вариант, можно рассмотреть привлечение нужных специалистов на аутстаф. Тогда нужно будет выделить только финансы, но не согласовывать дополнительные штатные единицы.
Выделение достаточного времени сотрудников заказчика на задачи обследования, чтобы выполнить их быстро. Выполнение предпроекта, включая подготовку необходимого набора документов, требуют существенных затрат времени специалистов, причем не только ИТ, но и бизнеса. Даже при условии активного использования ИИ, это все равно сложно вписывать в текущую деятельность без планирования и выделения отдельных ресурсов. Когда запускается обследование внешним подрядчиком, выделение ресурсов внутренней команды требуется в гораздо меньшей степени, и планирование проводится в рамках согласования и подписания договора. Когда же аудит – это чисто внутренний проект, время зачастую выделяется по остаточному принципу: пока собираются одни требования, другие, ранее собранные, уже успевают безнадежно устареть.
Взаимопонимание между ИТ и бизнесом. Для того, чтобы проводить интервью руководителей и сотрудников бизнес-подразделений, выявлять задачи, расставлять приоритеты, важно, чтобы бизнес позитивно воспринимал и проект по внедрению DWH, и ИТ-команду, которая им занимается. По опыту работы в GlowByte я вижу, что, к сожалению, заказчикам это далеко не всегда удается обеспечить. И часто причина кроется именно в ИТ. DWH часто рассматривается бизнесом как чисто ИТ-шная инфраструктурная платформа, не имеющая прямого отношения к задачам других подразделений. А ИТ зачастую, вместо того, чтобы пояснить на понятном языке, как хранилище помогает в решении множества актуальных задач – от отчетности до AI, – пытается сложно и непонятно рассказать о многочисленных технологиях, которые планируется внедрить, и бесчисленных технических сложностях, которые предстоит преодолеть. Чтобы преодолеть этот барьер, который критичен для нормального проведения обследования, нужно либо иметь на стороне ИТ специалистов, хорошо понимающих бизнес, либо привлекать таковых извне. Как проект “ИТ для ИТ”, внедрение DWH “не взлетает”, поэтому успешное самостоятельное обследование в качестве предварительного условия предусматривает наличие доверительных отношений ИТ и бизнеса.
Примеров, когда обследование даже для очень важных и сложных проектов делает сам заказчик, масса. Но далеко не все они удачные. Поэтому, принимая такое решение – в силу кажущегося отсутствия нужной экспертизы на рынке, сомнений в компетентности внешних подрядчиков во внутренних процессах, желания сохранить ключевые нити в собственных руках – стоит просчитать, есть ли необходимые ресурсы, чтобы сделать аудит достаточно быстро и с нужной детальностью. Ведь затянувшиеся сроки запуска проекта и подводные камни, которые всплывают в самый неподходящий момент, почти наверняка обойдутся дороже, чем привлечение внешнего ресурса.
А можно бесплатно?
Сразу скажу: конечно, можно и даже у нас в GlowByte такие примеры встречаются. Вопрос в том, будет ли сделанное бесплатно именно тем, что требуется,или всего лишь чем-то внешне похожим, но малополезным для целей, которые компания ставит перед этапом обследования.
Аудит – это априори еще не сам проект, а лишь предпроект. Он не дает значимых для бизнеса результатов, не приводит непосредственно к оптимизации процессов, повышению качества данных, ускорению принятия решений, снижению рисков. Такой проект на выходе лишь дает набор предварительных условий, которые требуются собственно для старта и выполнения основного проекта, который уже в свою очередь принесет все эти бенефиты. Поэтому необходимость платить за обследование почти всегда вызывает вопросы у клиента: “За что тут платить – за какие-то бумажки или презентации?”
С другой стороны, нормальное обследование DWH – это сотня человеко-дней, а бывает и гораздо больше. И это дорогие человеко-дни – старших и ведущих специалистов. Поэтому выделять их бесплатно нормальному подрядчику точно не с руки. Конечно, идеальный план – если все же есть возможность убедить держателей бюджета в необходимости профинансировать предпроект. Аргументов хватает, в том числе и в этой статье.
Если же бюджет на проект аудита никак не получить, есть несколько вариантов (конечно, помимо того, чтобы попытаться сделать все своими силами или “нагнуть” подрядчика на бесплатную работу ради хороших бизнес-перспектив – есть такие клиенты, которым трудно отказать в такой малости):
Минимизировать скоуп предпроекта и постараться убедить подрядчика, что вероятность старта проекта (в случае успешного завершения аудита) достаточно высока. Обычно, если есть реальная перспектива получить большой проект, потратить за свой счет 10-20 ЧД – даже с риском, что никакого продолжения не будет – вполне допустимо, и многие интеграторы на это идут. Конечно, бесплатно вряд ли получится проработать все настолько же детально, как в рамках полноценного обследования, но все же такой проект будет небесполезен и точно позволит снизить риски выбрать в ходе тендера не ту платформу и не подходящего подрядчика. Главное – расставить приоритеты и получить в рамках ограниченного бесплатного скоупа именно то, что вызывает больше всего опасений (например, проработать целевую архитектуру или собрать требования хотя бы к ключевому отчету).
Реализовать пилотный проект и в рамках его бюджета сделать обследование. Деньги на пилот у некоторых заказчиков находятся гораздо проще, чем на обследование, поскольку по его результатам получается осязаемый результат – развернутая платформа и реализованный (пусть и минимальный) скоуп с потоками данных, витринами, отчетами. Поэтому такой вариант может подойти тем, кто не может выделить деньги на “бумажки” или презентации, но готов финансировать проект, пусть небольшой и не очень ценный для бизнеса.
Включить стоимость обследования в скоуп будущего проекта (обычно в этап проектирования) и согласовать с подрядчиком, что все работы по предпроекту будут оплачены после того, как будет принято решение о запуске проекта и завершена его первая фаза. Речь в данном случае не о таком варианте, когда проект по внедрению запускается сразу без отдельного обследования, о чем я писал выше. Тут вопрос именно именно о схеме расчета с подрядчиком не живыми деньгами, а обусловленным обязательством: будет проект – будут и деньги за обследование. Понятно, что здесь есть риски для подрядчика: если проект не состоится, он ничего не получит. Но поскольку подрядчик, проводя обследование и выдавая качественный результат, может существенно увеличить шансы на позитивный исход, то многие готовы принять такой риск. Тем более что обследование полезно не только для заказчика. Подрядчику такой предпроект позволяет лучше понять ИТ-культуру клиента и полнее учесть организационные и процессные риски. Требования заказчика и задачи проекта по результатам аудита становятся на порядок яснее, поэтому у подрядчика будет гораздо меньше шансов существенно просчитаться со сметой и сроками и, как следствие, уйти в минус.
Один из существенных минусов бесплатного обследования – это то, что отношение к нему как со стороны подрядчика, так и со стороны заказчика менее серьезное по сравнению с обычным, платным. С учетом того, что на такой предпроект нужно выделять дефицитных экспертов и вовлекать крайне занятых специалистов от ИТ и бизнеса, из-за такого отношения сроки аудита могут растягиваться, и он гораздо легче может попасть в замкнутый круг “сроки->изменения->сроки”, о котором речь шла выше.
Если это критично, то можно провести обследование, не имея на него бюджета. Но это скорее исключение, чем правило, и такое обследование в любом случае будет менее детальным и, соответственно, менее полезным, чем полноценный предпроект с зафиксированным набором обязательств сторон по договору.
Почему ставки выше, чем в проекте внедрения?
Часто можно услышать от клиентов вопрос: почему средняя ставка по обследованию (стоимость проекта, деленная на планируемый объем трудозатрат на проект) выше, чем по обычным проектам – внедрения, разработки, миграции. Особенно этот вопрос актуален тогда, когда подрядчик уже работает с данным заказчиком и его ставки прозрачны для клиента, даже когда проекты выполняются по модели фикс-прайс. Заказчик, как уже писал выше, не получает какого-то явного бизнес-эффекта от аудита и, конечно, зачастую полагает, что такой проект должен быть если и не бесплатный, то предельно дешевый. А тут обнаруживает, что еще и ставки для расчета сметы установлены по высшей планке. Как от такого не расстроиться?
Но чтобы понять, почему так происходит, достаточно просто открыть структуру проектной команды и посмотреть на нее с точки зрения грейдов, сравнить эту структуру с проектом внедрения и т. п. Особенность в том, что в обследовании обычно участвуют только сотрудники подрядчика высших и старших грейдов. Аудит – это про необходимость много общаться с руководителями ИТ и бизнеса, анализировать и структурировать много информации, принимать сложные технологические решения и продвигать их через многие инстанции на комитетах и советах заказчика. Мидлы и тем более джуны тут практически бесполезны. Таким образом, высокая средняя ставка определяется высоким средним грейдом проектной команды, и ничего с этим не поделать. Ну, кроме разве что, скидки от подрядчика, которую он может предоставить, если понимает большие перспективы проекта, в том числе финансовые.
Кто что делает: команда аудиторов
Само обследование – это обычно не масштабный проект. Даже если это предпроект для большого проекта, он все равно будет сильно лимитирован по срокам и скоупу. Оптимальная команда от подрядчика на обследование по DWH – например, всего 3–4 человека. Бывает и больше, если объем задач разрастается, а сроки нужно держать под контролем, но в классическом варианте это задача для небольшой слаженной команды хороших экспертов.
То, что внутри проекта обследования есть все же разные предметные области, определяет и то, что команда, как правило,состоит не из одного человека. Бывают, конечно, универсалы – эрудированные и опытные абсолютно во всех областях, – но мне пока такие не попадались. При этом senior-эксперты в проекте почти всегда совмещают две-три роли без потери качества результата (например, архитектора, дата-инженера и специалиста по DQ) .
Итак, чтобы сделать полноценное обследование, в нем должны принять участие специалисты подрядчика как минимум с такими ролями: руководитель проекта (дорожная карта, план проекта, смета), архитектор (архитектура, сайзинг), дата-аналитик (описание источников), бизнес-аналитик (сбор требований, календарный план, смета), дата-инженер (профилирование данных, календарный план, смета), DevOps-инженер (техстек, нефункциональные требования, DR), DQ-инженер (профилирование данных в источниках, требования к DQ), DevSecOps (требования к ролевой модели, требования к ИБ).
Сколько специалистов конкретной роли потребуется и какие роли они будут совмещать, зависит от масштабов организации заказчика, от объема ожидаемых результатов (состава и глубины проработки задач), от того, какую часть работы клиент готов взять на себя – от организационной до технической, а также от состава проектной команды и, наконец, от скилов каждого ее члена.
Но не нужно забывать, что обследование не выполняется подрядчиком в вакууме. Потребуется плотное участие команды со стороны заказчика в течение всего срока проекта, потому что в противном случае либо результаты будут малопригодны для использования в проекте, либо на этапе сдачи-приемки предпроекта возникнет большая проблема: согласование в таком случае может затянуться на больший период, чем весь предыдущий этап сбора требований и подготовки документов. При этом (по опыту GlowByte) значительную часть уже выполненной работы потребуется переделать.
Со стороны заказчика критично участие не только ИТ, но и сотрудников бизнес-заказчика, причем включая тех лиц, которые принимают решения, занимая высокие позиции в компании. Извечная проблема согласования результирующих документов обследования (когда никто не хочет брать на себя ответственность и принимать риски того, что в итоге в ТЗ постфактум что-то окажется не так) частично “лечится” только интенсивным вовлечением ЛПР в процесс. Но на практике этой проблемы почти невозможно избежать хотя бы потому, что между предпроектом и проектом проходит какое-то время, и в организации что-то обязательно изменится – пусть не сам процесс, исходная система или отчет, а просто понимание какого-то вопроса. Поэтому борьба за стопроцентную выверку и актуальность итоговых документов очень похожа на борьбу с ветряными мельницами из известного романа.
Ехать, не ехать?
Нужно ли в рамках обследования высаживать команду на территорию заказчика или можно сделать все удаленно по ВКС и другим электронным каналам коммуникации. Если бы мы обсуждали, как делать проект обследования DWH в доковидные времена, то однозначно пришли бы к рекомендации, что нужно ехать. Все же обследование – это не только анализ имеющейся документации и, собственно, систем и данных. Нужно проводить интервью владельцев систем-источников, владельцев бизнес-процессов, руководителей подразделений. Проводить согласования, а зачастую и мозговые штурмы, чтобы выработать оптимальные решения в сложных случаях. Такое удобно делать, глядя глаза в глаза, в личном контакте.
Но в нынешние времена очень часто встречаются ситуации, когда сама команда заказчика распределена по всей стране, а кто-то даже находится за рубежом. Собрать всех в офисе в какие-то конкретные ограниченные сроки малореально. Добавим к тому, что некоторые заказчики находятся объективно далеко. У нас, например, есть проекты на Сахалине, в странах Центральной Азии. Командировки к таким заказчикам существенно увеличат бюджет предпроекта (а ведь на данном этапе финансирование ограничено, потому что бюджет на проект еще не выделен) и создадут дополнительные неудобства для команды, что приходится учитывать в нынешние непростые времена. Поэтому приходится подстраиваться под особенности момента, и большинство проектов по аудиту у нас проходят удаленно.
Есть тут, конечно, страновые особенности. Например, в странах MENA до сих пор принята работа в офисе, и того же требуют от подрядчиков, особенно в части ключевых специалистов. Конечно, при этом выделяют достаточный бюджет на то, чтобы люди могли добраться и комфортно разместиться, компенсируя все неудобства.
В целом я полагаю, что если есть принципиальная возможность поехать к заказчику (технически и финансово), то стоит запланировать хотя бы две командировки команды по неделе каждая. Одна – на проведение интервью с ключевыми лицами со стороны клиента (владельцами систем-источников, архитекторами, командой CDO, руководителями бизнес-подразделений). Вторая – на презентацию результатов заинтересованным лицам и обсуждение перспектив реализации проекта. Такие поездки позволят не только сделать сам проект по обследованию более предсказуемым, но и повысить (если вы будете достаточно убедительными) вероятность скорого старта самого проекта внедрения или миграции.
Сроки предпроекта. Почему так долго?
Сроки проведения обследования сильно зависят от скоупа проекта. Чтобы подготовить презентацию для руководства о том, почему данной компании стоит внедрить хранилище данных, какую она получит от этого пользу, какие конкуренты уже внедрили ХД и что они от такого внедрения получили, обычно не требуется больше месяца. Понятно, что такая презентация должна все равно быть “заточена” на текущее состояние заказчика и стоящие перед ним проблемы, но все равно, если не возникает каких-либо неожиданностей (главный бизнес-заказчик вдруг уехал в отпуск на месяц), можно справиться даже быстрее.
Но если требуется полноценное обследование со сбором требований и пр., то “нагнать” команду аналитиков, чтобы они все сделали за пару недель, вряд ли получится. Многие задачи в проектах взаимосвязаны, и обследование не исключение.
Обычно исследование в ходе предпроекта идет сверху вниз: от требований к отчетам, к требованиям к витринам, детальным данным и далее – вплоть до источников. Но, например, согласовать требования к качеству данных сложно, пока не разобрались, что за данные нужны, с какой периодичностью их нужно обновлять, с какой гранулярностью загружать.
Требования к интеграции бессмысленно собирать, пока не понятно, из каких источников какие сущности загружать (данные по одним и тем же сущностям могут содержаться в разных источниках, как, например, клиенты, которые могут быть в CRM, MDM, АБС, платежной системе и еще много где), какие SLA по времени загрузки и каковы общие объемы данных, которые требуется прогружать за один раз. А может быть, задача вообще обновлять информацию в реальном времени – тогда придется предлагать способы интеграции совсем не те, что для пакетного процесса обновления раз в час.
Тем не менее главным фактором, почему не получается сделать аудит быстрее, обычно является возможность выделения ресурсов со стороны заказчика: для предоставления информации в ходе интервью, для участия в обсуждениях и согласования промежуточных результатов, для выверки и приемки финальных результатов проекта. Этот ограничитель многим кажется несущественным, особенно когда заказчик на старте реально мотивирован сделать проект и, казалось бы, готов жить на работе, чтобы быстрее получить нужный ему результат.
Но на практике все упирается в процессы на стороне клиента, в размывание ответственности по организационной структуре, в специалистов или руководителей, которые головы не могут поднять из-за огромной текущей загрузки и с которыми о часовой встрече приходится договариваться за месяц. А за час до встречи они могут сообщить, что именно на это время им назначили встречу в Налоговой, в Правительстве или ещё где-то, и они не могут ее пропустить.
Таким образом, изначально согласованный и вполне нормальный план обследования в два-три месяца легко может превратиться в полгода и даже больше. При этом мало того, что подрядчик несет убытки и не может удержать сильную команду на проекте (ее оплата фиксирована и объем денег рассчитывался исходя из начального срока), – клиент вынужден сдвигать сроки запуска основного проекта, откладывать получение ожидаемых от него результатов, а ведь на этих результатах часто завязаны большие бизнес-эффекты. Я уж не говорю о страданиях проектных команд с обеих сторон, не выполняющих свои КПЭ, – на это на фоне более глобальных проблем зачастую вообще не обращают внимания.
Извечный вопрос: что можно сделать, чтобы сократить сроки или по крайней мере получить их реальную оценку “на берегу”?
Первое – как можно точнее определяться со скоупом: количество систем-источников, сущностей, таблиц, бизнес-доменов, которые попадают в периметр проекта. Насколько глубоко нужно будет копать – лучше даже прямо согласовать состав разделов и предполагаемый объем всех результирующих документов. Опытный подрядчик всегда сможет предоставить обезличенные примеры, подготовленные на основе предыдущих проектов.
Если есть возможность взять подрядчика, который уже работал с этим клиентом ранее, это плюс: он как минимум знаком с корпоративной культурой компании, сделает правильную поправку на реально имеющиеся риски и будет стремиться их митигировать, понимая, с чем нужно бороться, а с чем бесполезно – и что нужно просто принять как есть.
Ну и, конечно, желательно исключить такие подходы, когда изначально на подрядчика оказывается последовательное давление, чтобы он ужимал планируемые сроки проекта. Сначала руководитель проекта, потом CDO, потом CIO настаивает, что нужно ужаться на как минимум на пару недель, а иначе никак. В итоге плановый срок проекта становится заведомо нереалистичным, рассчитанным исходя из идеальных предпосылок: что никакие риски не сработают, что все согласования будут выполняться за один день. А когда риски срабатывают, то это бьет как по подрядчику, так и по всей цепочке ответственных лиц на стороне клиента.
Отдельно хочу подчеркнуть, что, как и у любого проекта, у обследования есть ограничение сверху. 2–3 месяца – это нормальный срок. 4 – это еще куда ни шло. Но растягивать такой проект больше чем на полгода крайне опасно.
Основной риск: обследуемый ландшафт и требования к проекту за такой срок могут измениться настолько сильно, что значительную часть проделанной работы придется отправить в корзину. Возникает замкнутый круг из растянувшихся сроков проекта и быстрых изменений, порождающих изменения требований. Выйти из этого круга сложно и для подрядчика, и для заказчика.
Существенные изменения требований часто требуют значительного времени для их анализа, переработки множества уже подготовленных документов, пересогласований на всех уровнях. За это время еще что-то меняется – и так по кругу.
Поэтому стоит трижды подумать, стоит ли накидывать дополнительные требования, даже если кажется, что без них результат не на 100% соответствует самым последним изменениям в таблицах и схемах. Все равно в ходе уже собственно проекта требования уточняются, и от этого этого никуда не уйти.
В большинстве случаев предлагаемые изменения не критичны и только растягивают согласования, особенно когда их генерацией занимаются не участники проектной команды, а широкий круг лиц, которые хоть как-то причастны к теме. Все эти затяжки в итоге могут привести к дополнительным месяцам задержки сдачи предпроекта и загнать его в вышеописанную петлю.
А как же Agile?
Зачем вообще проводить отдельное обследование, писать кучу документов, если можно работать по Аджайлу, реализовывать проект небольшими спринтами по две-три недели, продвигаясь фича за фичей. Можно же, действуя таким образом, собирать небольшой пул требований, быстро делать и выводить в прод.
Такой метод хорош и работает в области DWH тоже, но только в проектах развития, когда базис (архитектура, фреймворки, процессы, ИБ, DR) уже выстроен и требуется планомерно наращивать в ХД разнообразие и объем данных, поддерживая прикладные задачи бизнеса.
Для запуска же проекта с нуля или для большой миграции (например, в рамках импортозамещения) Agile зачастую губителен. В силу особенностей методологии, ее применение при старте такого проекта, как запуск DWH, почти наверняка приведет к тому, что срок проекта растянется в три раза (из-за постоянных неожиданных препятствий и неоднократных переделок уже выполненной работы), а удовлетворенность пользователей окажется, если не на нуле, то близко к этому.
В общем, я считаю, что при запуске проекта ХД без обследования, подготовки и согласования всего набора нужных артефактов никак не обойтись.
Мы не эксперты. Вы сами скажите, как правильно
При реализации проекта обследования возможны три разные позиции заказчика по взаимодействию с подрядчиком.
1. Безапелляционная экспертная позиция
Иногда заказчики выступают с позиции: “Я сам все знаю, как делать, но мне не хватает рук оформить нужные бумажки” (для тендера, для запуска проекта и т. п.). В таком случае тоже хорошо бы прислушаться к грамотному и опытному подрядчику хотя бы по наиболее спорным вопросам. Но, как говорится, насильно мил не будешь, и если ИТ-компанию наняли оформить сформировавшееся уже внутри ИТ-департамента мнение, то вряд ли получится плыть против течения.
2. Сбалансированная коммуникация
Чаще в ходе обследования возникает сбалансированное взаимодействие заказчика и подрядчика, когда стороны взаимно обогащают друг друга. Со стороны заказчика – глубокое понимание реалий бизнеса компании, ее процессов, ограничений. Со стороны подрядчика – понимание сложившихся на рынке практик, передовых технологий, сформированных трнендов, методических подходов. Это для обеих сторон самый оптимальный вариант.
3. Позиция “Вы эксперты – вы и скажите как надо”
Отнюдь не редко возникает ситуация, когда заказчик занимает позицию: “я ничего про эти технологии не знаю, я в этом не разбираюсь. Вы эксперты, вы и скажите, как надо, как правильно”. Казалось бы, подрядчик схватил удачу за хвост: к нему прислушиваются, его мнение ценят, свое мнение не продавливают. Работай с удовольствием. Но в реальности такой подход заказчика в большинстве случаев нацелен не на то, чтобы принять экспертное мнение подрядчика, а на то, чтобы снять с себя ответственность за принятие проектных решений (которые априори должны лежать в зоне ответственности заказчика).
Рано или поздно истинная причина вышеприведенного поведения становится ясной. Сдать проект в такой ситуации на порядок сложнее, чем при обычном сбалансированном подходе. Будут десятки согласований, огромное число вовлеченных со стороны заказчика лиц, каждый из которых будет пытаться переложить ответственность за приемку документов на других. И в конце, скорее всего, последует попытка полностью перечеркнуть подготовленные подрядчиком результаты, возможно даже с привлечением третьей стороны.
В общем, если вы заметили первые звоночки в виде заявлений “вы эксперты – вам виднее”, я рекомендовал бы не радоваться, а хорошо подумать о том, как можно быстрее выйти из такой ситуации. Как вернуть заказчика из позиции “я тут ни при чем” в позицию реального заказчика предпроекта и безусловного ответственного за ключевые решения в проекте.
Параллельные активности. Все в сад за скоуп
Разумное ограничение скоупа обследования – необходимое условие для того, чтобы сделать проект в приемлемый срок и не превратить его в бесконечный и бессмысленный марафон. Но если мы говорим об обследовании такой значимой области ИТ-инфраструктуры, как хранилище данных, то неизбежно возникает множество смежных элементов и непреодолимое желание включить в состав задач предпроекта и эти дополнительные темы.
Обычно к таковым относится BI, DG/DQ, MDM, НСИ и, конечно, обязательный сегодня AI.
Почему BI – понятно: он является первым и зачастую единственным потребителем данных ХД и, соответственно, исходным источником требований: какие отчеты/дашборды делаем, какие показатели и в каких разрезах нужно считать, какие сущности с какими атрибутами для этого нужны, в каких источниках и в каких таблицах они лежат.
Но и остальные функциональные блоки тоже тесно связаны с ХД . Без внедрения Data Governance как процесса управления данными сложно будет понимать, что и в каком виде есть в хранилище, что, как и на чем считается, кто отвечает за какие домены данных и т. п. Без Data Quality сложно выстроить управляемый процесс проверки качества загружаемой информации и обеспечить для пользователей прозрачность метрик качества используемой ими информации.
Справочники (RDM) являются одним из ключевых элементов хранилища данных. Если они ведутся в многочисленных Excel-файлах или дублируются в разных системах источниках, то все эти проблемы проецируются напрямую в результаты работы аналитических систем.
В общем, все эти дополнительные блоки безусловно важны для работы хранилища, и в последние годы сформировался тренд, когда их внедрение делается не последовательно (сначала соберем данные в ХД, а потом уже опишем все в DG), а параллельно, с одновременным запуском нескольких функциональных стримов.
Только необходимо помнить, что упомянутые дополнительные блоки, даже если они стартуют и выполняются одновременно в внедрением ХД, должны быть отдельными проектами – со своей командой, своими планами, задачами и требованиями. Поэтому и обследование по этим темам нужно проводить в форме отдельных проектов, не замешивая все один монструозный предпроект, который имеет мало шансов на быструю реализацию – и в силу скоупа, и ввиду большого числа участников и согласующих лиц.
Выбор аудитора. Все как обычно, но есть нюансы
Понятно, что цена, опыт, репутация при выборе любого подрядчика в любом проекте играют важную роль. Но здесь я хотел бы обратить внимание на особенности выбора команды именно для предпроекта.
В успехе обследования как чисто консалтингового проекта ключевую роль играет наличие в команде подрядчика требуемых экспертов: их опыт и знания тут критичны как никогда. Вопрос в том, что зачастую заказчику сложно объективно оценить таких экспертов. Ведь во многих случаях он потому и приглашает внешнюю команду, что собственной экспертизы в предметной области не хватает.
Не очень стандартная практика, когда запуская проект с фиксированной ценой (а обследования редко делаются по T&M), заказчик настаивает на проведении собеседований с членами проектной команды. Ведь подрядчик подписывается под результат и при этом сам определяет, какая команда будет на его стороне и кто что будет делать.
Но обследование в этом смысле можно отнести к исключениям. Команда здесь относительно небольшая, она должна включать в себя реальных экспертов. Работать они будут не над разработкой кода в бэкенде, а по большей части на “фронте”, взаимодействуя с заказчиком, представляя и согласовывая сначала основные предложения по проекту, а потом и результирующие документы.
Поэтому именно убедительность и экспертность членов команды подрядчика на встрече должна быть для заказчика приоритетным критерием. Причем согласиться с тем, что эти люди подходят, должен и ИТ, и бизнес. Фактически заказчик, посмотрев и послушав представленных специалистов, должен довериться им, их мнению по ключевым вопросам.
“Доверенный партнер” в обследовании – не просто фигура речи, а абсолютная необходимость. В условиях, когда экспертиза в новой для заказчика области, технологии, процессе существенно ниже требуемой для старта проекта, ему придется положиться на мнение выбранного подрядчика. И здесь критически важно, чтобы это доверие сложилось с самого начала.
Если подрядчика на обследование выбирают за низкую цену (что у нас не редкость), но доверия к его экспертизе у клиента нет, то есть очень большой риск: все согласования затянутся надолго, и прийти к консенсусу будет крайне сложно.
Харизматичный аудитор – это скорее не благое пожелание, а рекомендация. А в условиях, когда внутри компании клиента нет единства по тому, как и что нужно делать в предстоящем проекте, харизма подрядчика становится ключевым фактором, который поможет примирить стороны. Поэтому на нее стоит обращать особое внимание.
Еще одна классическая, но весьма полезная рекомендация для выбора команды для проведения обследования – это попросить у потенциального подрядчика примеры выходных артефактов: обезличенные документы с предыдущих проектов или даже просто структуру с отдельными фрагментами текста, релевантными для того типа обследования, которое планируется провести.
Так можно гораздо лучше (чем по красивым продающим презентациям) понять, насколько детально будет прорабатываться задача, насколько структурировано и четко подается итоговая информация, какой объем предполагается выдать в качестве результата.
Изучив эти материалы, можно либо убедиться, что мнение о том, как должны выглядеть результаты у заказчика и подрядчика, близки, либо скорректировать требования, чтобы подрядчик заложил сформулированные ожидания в оценку. Иначе потом может получиться, что он выдаст 20 страниц вместо ожидаемых 100, и недостающую детализацию из него придется “выжимать” еще долго – с болью и стрессом для всех сторон.
AI – сам пишет, сам читает, пока еще сам не решает
Любую задачу сегодня в первую очередь проверяют на то, нельзя ли сделать ее (хотя бы частично) с помощью ИИ. Искусственный интеллект уже не только пишет статьи и рисует картинки, но и разрабатывает программы, и автоматизирует процессы.
Обследование, результатом которого является именно набор документов, довольно хорошо подходит для применения ИИ. В GlowByte, например, уже есть фреймворк, который может сам подготовить набор базовых артефактов обследования, если ему предоставить полный набор входящих документов с требуемой информацией: интервью, исходные требования и ТЗ, документацию на системы, регламенты процессов, презентации, проектную переписку, метаданные схем и таблиц БД.
На выходе получается пакет, включающий бизнес-цели и критерии успеха, описание текущего процесса (AS-IS), функциональные требования, диаграммы, глоссарий и матрицу соответствий и пр. Агент идет по шагам, создавая отдельный файл на каждом этапе. Результат каждого шага можно посмотреть и сразу поправить.
ИИ безусловно упрощает подготовку базовых документов. Сразу дает нужную структуру, формирует требуемые таблицы и архитектурные схемы. Но, конечно, результат работы агента пока требует выверки и устранения неточностей, исключения лишней информации.
ИИ дает ускорение на стороне подрядчика, но это приводит к еще более серьезной зависимости сроков проекта от возможностей приемки и согласования на стороне заказчика. Вероятно, когда и заказчики будут принимать результаты работы с помощью отлаженного ИИ-помощника, тогда можно будет говорить о существенном ускорении проведения обследования в целом. Пока до такой стадии мы еще не добрались.
Ну и не стоит забывать, что ИИ прекрасно работает с большим объемом качественной информации: восстанавливает зависимости, описывает, структурирует. Но если в исходных данных много проблем или их вообще нет, то эффект от применения ИИ может быть существенно ниже ваших ожиданий.
Как продать обследование?
Когда мы слышим слово “продать”, перед мысленным взором всплывает приторное лицо сейлза, который пытается впарить нам что-нибудь совсем не нужное. Конечно, обследование – не тот товар, который можно продавать с помощью холодных звонков. Но продавать его приходится. Подрядчику идею обследования обычно продавать не нужно. Ему ведь совсем некомфортно подписаться под мутными верхнеуровневыми требованиями на несколько страниц, подготовленными на проект, который оценивается в несколько тысяч человеко-дней. Поэтому он заинтересован в подготовке актуального и максимально полного контента, на основании которого можно более-менее точно оценить и спланировать проект. Заработать на обследовании малореально, поэтому продажа здесь – скорее не ради денег, а для минимизации рисков потерь (денег и репутации) уже в проекте.
Но внутри самого заказчика предпроект приходится продавать, потому что когда окажется, что сделанное в проекте слабо коррелирует с реальными потребностями бизнеса и никак “не натягивается” на процессы компании, обязательно найдется виноватый – и это будут не только внешние участники проекта.
Первое, что на что стоит обратить внимание: невозможно продать полномасштабное обследование, если для заказчика тема самого проекта как таковая пока не очевидна.
Представьте: ХД компании прекрасно работает на Oracle, и в компании не понимают, зачем тратить большие деньги на миграцию на альтернативную платформу (“Не отключат ведь в конце концов”). В такой ситуации максимум, что стоит предложить, – это провести экспресс-аудит и подготовить презентацию с вариантами развития и их обоснованием. Как писал выше, это можно сделать за несколько недель без сильного вовлечения заказчика и за совсем скромные деньги.
Если заказчик уже “созрел” для того, чтобы запускать проект (например, собирается проводить конкурс), но у него нет четкого понимания по бюджету, срокам, необходимым ресурсам на своей стороне, а собранные требования очень верхнеуровневые, то здесь действительно стоит попробовать продвинуть идею проведения предпроекта.
Лучший способ обосновать проведение аудита – взять документы самого заказчика – обычно это техническое задание. Затем подобрать пример аналогичного ТЗ (или набора документов), который был подготовлен подрядчиком в рамках похожих проектов, и конкретно по пунктам показать отличия в степени проработки и детализации. Важно пояснить, какие конкретно риски реализуются, если такую работу не выполнить.
Например:
Что будет, если не включить в состав требований подходы к реализации DR именно в том виде, как требуется заказчику?
Или что будет, если забыть про то, что ролевая модель должна работать для всех компонентов дата-платформы (а их в современных архитектурах может быть множество), а не только для СУБД?
Как можно просчитаться с объемом работ и с требованиями к “железу”, если не учесть специфику захвата данных из разных источников?
Насколько существенным может быть дополнительный объем работ, если в рамках миграции на новый стек меняется архитектура и модель ХД?
Нюансов много, и перечислять их на страницах этой статьи нет смысла, но важно поработать именно над документом самого заказчика: показать на конкретных примерах, что именно там нужно проработать и чем грозит, если этого не сделать.
“Продажа” обследования внутри заказчика как правило связана с необходимостью оценки (лучше даже в деньгах) рисков того, что компания зайдет в проект, не имея четкого, атуального, согласованного между бизнесом и ИТ ТЗ, включающего требования к оборудованию, описание архитектуры, детальный план работ, ресурсный план, смету.
Для многих заказчиков сегодня критично наличие детально проработанного списка требований информационной безопасности к системе – причем не абстрактного универсального документа “за все хорошее против всего плохого”, а конкретно сфокусированного на данном классе систем, данном стеке и архитектуре, который реально можно реализовать за конкретные деньги и в оговоренные сроки. Если под этими требованиями подпишется доверенный подрядчик с опытом реализации подобных проектов, а также заинтересованные стороны внутри заказчика, то гораздо больше шансов, что итоговое решение получится более выверенным и защищенным, чем если полагаться на то, что в дальнейшем подрядчик сам как-то все продумает и сделает “как надо”.
Аудит обычно не такой уж дорогой проект, чтобы речь шла о выделении бюджета на уровне акционеров и совета директоров. Даже для средних организаций, не говоря уже о лидерах отраслей. Поэтому вопрос скорее не в том, чтобы найти деньги на предпроект, а в том, чтобы обосновать целесообразность и выгоду от проведения такого обследования для всех сторон внутри заказчика. Ведь риски несет не только ИТ, но и бизнес, и компания в целом.
Причем обычно риски проблемных проектов внедрения КХД оказываются на порядки больше, чем стоимость любого, даже самого детального обследования с привлечением самого профессионального подрядчика.
Заключение
Современные условия, казалось бы, не способствуют росту популярности предпроектных обследований. Мы в GlowByte видим, что многие заказчики, даже проводя тендеры на внедрение крупных решений, пытаются обойтись малой кровью: что-то как-то собрать, запаковать в форму тендерного задания (где зачастую общие положения о закупках занимают в несколько раз больший объем, чем сутевая часть требований) и запускают таким образом проекты на десятки и сотни миллионов.
Дополнительно способствует такому подходу наша действительность: изменения в компаниях резко ускорились, многие проекты идут по Agile, инвестиции сокращаются, а искусственный интеллект кажется панацеей для решения любых задач.
Тем не менее есть области, где, на мой взгляд, до сих пор сложно обойтись без предпроекта. А вход в большой проект без этого несет значительные риски для обеих сторон, и вероятность реализации этих рисков без предварительного обследования очень высока. Примером таких областей (но далеко не единственным) является внедрение корпоративного хранилища данных или миграция его на новую платформу/ новую концепцию.
Если ожидаемый срок реализации предполагаемого проекта превышает 6 месяцев; если требования, собранные заказчиком, вызывают разночтения и приводят к очень разным оценкам уважаемых подрядчиков; если не хватает собственных компетенций или ресурсов для того, чтобы детально проработать полный набор упомянутых выше артефактов для успешного запуска и реализации проекта внедрения, – то нужно как минимум подумать о том, чтобы заказать обследование. Да, вы потратите немного денег и два-три месяца на эту работу, но оно того стоит: это не только окупится, но и поможет сохранить много нервов и здоровья всем участникам масштабного и гарантированно непростого проекта.
