Безумие RFI, RFP и RFQ в цепи поставок

Joannes Vermorel

На протяжении многих лет Lokad завоевала некоторую известность, и мы получили привилегию стать частью все более большого числа RFI (запрос на информацию), RFP (запрос на предложение) и RFQ (запрос на котировку), связанных с оптимизацией цепи поставок. Хотя я благодарен за то, что Lokad считается достаточно заметной для включения в эти инициативы - и регулярно выбирается также - я не могу не задуматься о безумии, лежащей в основе этих процессов.

Я долгое время был озадачен странными практиками, которые преобладают в области предприятийного программного обеспечения ¹. Более недавно я также предложил подход, который я считаю куда более превосходным во всех аспектах по сравнению с основными ². Однако сегодня я хотел бы рассмотреть некоторые из явно странных (если не сказать безумных) элементов RFP, которые я наблюдал. Вкратце, RFP ³ - это научизм в действии. Взгляд, отношение и процесс, которые подражают в глазах широкой аудитории тому, каким ожидается, что будет выглядеть “научное” предприятие. Однако на практике RFP примерно такие же научные или рациональные, как сеанс.

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

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

• Ленивые вопросы. Пример: Следует ли решение лучшим практикам безопасности? Эти вопросы просто тратят время всех. Ни один поставщик предприятийного программного обеспечения, в здравом уме, никогда не даст отрицательный ответ на такой вопрос. 
• Глупые вопросы. Пример: Управляет ли решение MOQ (минимальными объемами заказа)? Эти вопросы добавляют путаницу. Управление MOQ тривиально; сложно делать любой вид оптимизации в присутствии MOQ. 
• “Умные” вопросы. Пример: Как решение рационализирует расхождения прогнозирования с исходным планом в условиях отсутствия товара на складе? Я предполагаю, что эти вопросы (кажущиеся точными, но на самом деле неопределенными) предназначены для впечатления коллег, но они только добавляют дополнительный уровень путаницы, вскоре усугубляемый таким же флоридным ответом поставщика программного обеспечения.
• Загрузочные вопросы. Пример: Предлагает ли решение возможность управления и настройки профилей сезонности? Эти вопросы вмешиваются в нейтральность процесса и подразумевают дополнительные неявные вопросы. Примерный вопрос подразумевает, что сезонность должна рассматриваться через “профили” (почему?) и что в них должны быть вовлечены конечные пользователи (почему?).
• Неоднозначные вопросы. Пример: Позволяет ли решение вводить КПИ (ключевые показатели эффективности)? Этот класс вопросов усугубляет недоразумения. Что является КПИ (ключевым показателем эффективности) - это вопрос субъективный; поставщик и клиент вряд ли разделяют одинаковые взгляды на этот счет.
• Побочные вопросы. Пример: Может ли решение пересчитывать свои рекомендации по пополнению в режиме реального времени? Эти запросы отвлекают от основных вопросов. Понятие “реального времени” в области распределенного корпоративного программного обеспечения включает в себя долгие, чрезмерно технические обсуждения, которые в конечном итоге не имеют значения, если исходные данные по пополнению являются некорректными.
• Пугающие вопросы. Пример: Сертифицировано ли решение по стандарту ISO/IEC 27001? Такие вопросы дают преимущество неправильным сторонам. Сертификация в корпоративном программном обеспечении дает власть сертифицирующим органам и их экосистеме, но не приносит никакой ценности для клиентской компании.

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

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

Я также должен отметить, что (почти?) все документы RFP отражают в своей презентации довольно грубое небрежное отношение. Каждый параграф сопровождается ужасными орфографическими ошибками. Есть повторяющиеся вопросы и повторяющиеся номера вопросов. Размер шрифта неуклюже меняется от 6 до 20, а документ заполняют случайные переносы строк. Что касается вопросов, то тут еще хуже, так как RFP обычно форматируются в виде электронных таблиц Microsoft Excel - разбитых на несколько вкладок, каждая из которых имеет свои столбцы “Вопрос” и “Ответ”, а также несколько других для надежности (например, приведенный выше пример “Соответствия”). Формат электронной таблицы не имеет никакого смысла в контексте RFP. Пользовательский опыт - будь то написание или чтение многоабзацного контента в ячейке электронной таблицы - является ужасным; тем более, когда вопросов сотни, как это обычно и бывает.

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

Наивно думать, что форма не имеет значения, пока есть суть. Форма RFP, несмотря на свою отвратительность, гарантирует, что погружение в вопросы, не говоря уже о ответах, является огромной тратой времени. В результате, люди, которые должны были бы возглавить процесс выбора - такие как директор по цепочке поставок - отступают и делегируют свои полномочия “экспертам”, таким как менеджеры по закупкам или третьи стороны. Менеджеры по закупкам обычно имеют мало представления о том, что является разумным решением для их собственной компании. Тем временем, третьи стороны, привлеченные в качестве фасилитаторов RFP, стимулируют сделать это предприятие максимально запутанным.

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

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

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

Несмотря на все эти проблемы, RFP широко распространены в корпоративном программном обеспечении. Однако, в частных беседах большинство людей - по крайней мере те, кто не зарабатывает на RFP - признают, что процесс имеет мало смысла, что делает распространение RFP еще более загадочным. Самое простое объяснение, которое я могу предложить, заключается в том, что RFP являются сложной формой корпоративного “сигнала добродетели” ⁷. В эпоху информационных технологий признание того, что крупное решение может быть принято на основе ничего более, чем образованного предположения, неприемлемо и воспринимается как упрощенное, недостаточно сложное и совершенно не научное. Процесс RFP может не приносить никакой ценности для компании, но он полностью удовлетворяет аспекту сигнализации добродетели.