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

Joannes Vermorel

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

Долгое время меня озадачивали странные практики, распространенные в сфере корпоративного программного обеспечения ¹. Недавно я предложил подход, который, я твердо верю, превосходит все мейнстримовые методы по всем параметрам ². Однако сегодня я хотел бы разобрать некоторые откровенно странные (если не прямо безумные) элементы RFP, которые мне довелось наблюдать. Короче говоря, RFP ³ — это наука в действии. Подход, отношение и процесс, которые в глазах широкой аудитории должны напоминать, каким по идее должен быть «научный» процесс. Однако на деле RFP так же научны и рациональны, как сеанс спиритизма.

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

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

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

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

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

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

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

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

Кто-то может утверждать, что RFP — это меньшее зло по сравнению с откровенным подкупом, который мог бы возникнуть при его отсутствии. Иными словами, несмотря на их изъян, RFP остаются самым безопасным вариантом для сохранения целостности компании и процесса выбора. Однако это довольно экстраординарное утверждение, которое требует экстраординарных доказательств. Действительно, это вызывает вопросы относительно того, какое мошенничество именно должны предотвращать RFP и, соответственно, насколько они эффективны в этой задаче. Откровенно говоря, идея о том, что проведение большого процесса отбора через не менее большую и случайную таблицу делает процесс «более честным», на первый взгляд выглядит весьма натянутой. (Извините за мой скептицизм.)

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

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

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