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

Joannes Vermorel

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

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

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

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

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

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

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

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

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

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

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

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

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

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