Закупки по Agile

Гибкость процесса закупок является большой проблемой для многих организаций. Мы стараемся повысить гибкость во всей нашей рабочей деятельности, а зачастую именно подразделение, отвечающее за закупки, становится той бетонной стеной, в которую мы со всего разгона влетаем. Так считает Роб Ингланд (также известный как ИТ-скептик). По его личному опыту, поиск подрядчика может занять несколько месяцев, что делает работу невозможной. В своей недавней заметке он высказывает мнение о том, как можно изменить подобную ситуацию.

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

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

По мнению Роба, которое он вынес по результатам обсуждения в группе Back2ITSM в Facebook, RFP (request for proposal, запрос предложения) — хорошая иллюстрация проблемы. Деятельность в части запросов предложений — способ избежать ответственности: показное действо, чтобы обосновать решение, которое зачастую уже принято. В этом корень избыточности правил и процедур.

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

Использование RFP в равной мере дорого обходится и для самого покупателя. Требования в RFP могут быть составлены не всегда ясно и понятно, что оставляет простор для поставщиков для двусмысленностей и широкого трактования требований — всегда можно ответить утвердительно, а потом пояснить, что именно подразумевалось. Поскольку ответы составлены в жёстких рамках юридического языка, то обсудить что-то детально и налегке не получится. Отбор предложений, прошедших по конкурсу, может занимать 6 месяцев вместо 6 дней, характерных для разработки ПО. Завершается работа сравнением предложений, различающихся между собой на доли процентов. А разница возникает вследствие произвольного трактования неоднозначного текста предложений и субъективизма в оценках жюри.

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

Поскольку ничто не является совершенным и обычно не соответствует требованиям полностью, то вашим основным критерием должен быть не принцип точного соответствия, а сам поставщик:

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

Пригласите технических специалистов поставщика на воркшоп, внимательно к ним присмотритесь, оцените уровень технической подготовки.

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

Идите на риск. Создайте среду осознанного и приемлемого уровня риска, заключает Роб.

ITIL ITIL Practitioner — новый учебный курс 2016

Правильный следующий шаг после ITIL Foundation.
 

Узнайте больше!

Комментарии и мнения

  1. Андрей

    Мне кажется скорость закупки может являться одним из критериев успешности организации.

    Можно даже его использовать, как вопрос работадателю при приеме на работу:

    «А какое время проходит с момента появления потребности во внешнем ресурсе до момента удовлетворения этой потребности?»

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ДЕК
17
Учебный курс:
Основы DevOps 
ДЕК
20
ДЕК
20