RFP: покойтесь с миром

Пришло время выбросить за ненадобностью RFP, существующие только благодаря организационной косности.

Некий болезненно честный администратор информационной системы предприятия недавно рассказывал об ужасно запутанных и беспомощных предложениях для обсуждения (request for proposals - RFP), подготовленных в его компании для крупного системного проекта.

По его словам, эти RFP, скорее, напоминали отчаянный крик о помощи, чем четко сформулированные требования к системе.

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

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

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

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

Большинство организаций сами не знают, что хотят получить. А если бы знали, то им не нужны были бы никакие RFP.

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

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

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

А как же насчет того, чтобы в качестве отправного пункта рассматривать системы, работающие в других компаниях?

К сожалению, сегодня специалисты по информационным системам больше занимаются описанием того, как система должна была бы работать, чем ее созданием. Так что, по-моему, RFP - это все-таки к беде.