Почему пытаются, а не воруют? Если честно, из множества закупок, которые попали в поле моего зрения, не удалось остановить только примерно полторы (пару государевых закупок не считаем, там своя специфика). Одну – просто поздно заметили, а половинка – «планового» контрагента заменили, но не с оптимальной ценой. Как обычно бывает, заслуга это не столько внутренних аудиторов, но и системы управления в том числе.

Под закупками IT мы понимаем все закупки, включаемые в бюджет IT. Направлений там много, но схема закупки, не поверите, примерно одинакова и для Software (грубо говоря, программное обеспечение), и для Hardware (т.н. железо), и для коммуникаций в широком смысле (естественно, без городской и даже сотовой телефонной связи).

Введение (особенности рынка IT).

Для начала – несколько отличий рынка IT от других рынков.

Отличие 1. В России нельзя купить напрямую у вендоров. Например, если Вы захотите купить на БелАЗе самосвал, это будет сложно, но можно. Про рынок IT такого сказать нельзя. Даже в компании, про которую в википедии написано, что маркетинговая стратегия – «Товар реализуется непосредственно покупателю, минуя посредников».

Отличие 2. Правила игры на этом рынке (говорю только за Россию) таковы, что если Вы решите купить лицензии или железяку A у производства/поставщика B, то с высокой вероятностью контрагента Вам назначат. Ну, то есть по внешним признакам Вы думаете, что идет какая-то конкурентная борьба, поступают коммерческие предложения, в тендерах есть несколько разумных участников. Но, увы, победитель заранее известен директору по IT и участникам всех этих действий. Можете назвать это особенностями рынка, можете назвать это хамством официальных представительств всех мировых компаний на территории РФ, можете назвать это картелем, смысл сохраняется. Называется это «защитой проекта». В принципе, оно встречается и на других рынках, но только в IT оно практически везде.

Отличие 3. Вы практически никогда и нигде не сможете узнать реальные цены оборудования, лицензий и услуг. Понятное дело, что если IT-шник приносит Вам документацию, в которой утверждается, что 1000 мониторов будут стоить за штуку без НДС дороже, чем один на яндекс.маркете в розницу, сомнения возникнут (ситуация реальная, лично встречались с «назначенным» поставщиком. Кстати, проиграл в конкурсе). Но это – редкость. А вот на вопрос, сколько стоит даже банальный сервер – очевидного ответа нет. Может 500, а может 2500… Прайс-листы – не более, чем какое-то обоснование начальной максимальной цены, но при этом эта цена позволяет учесть интересы всех участников цепочки поставок.

Учитывая всё вышеизложенное, перед директором по IT стоит задача убедить всяких контролеров (например, комитет по информационным технологиям, закупочную комиссию, финансового директора) в том, что без покупки конкретной железяки/набора ПО/… конкретного производителя/вендора дальнейшее существование предприятия может быть прервано. IT-шники  делают, как правило, три традиционных шага, которые рассмотрены ниже.

Шаг 1. Определение круга поставщиков.

Задача этого шага – выбрать 2-4 компании, из которых будем принципиально «выбирать» в дальнейшем.

Начинаться всё должно красиво, поэтому директор по IT обращается к публичной информации мировых аналитиков, а именно к исследованиям компании Гартнер. Почему именно к ней, а не к условной IDC? Потому что Gartner публикует т.н. магические квадранты по конкретному направлению в виде красивой матрицы 2×2 со всеми мировыми лидерами. Обоснование с картинками лучше, чем обоснование без картинок.

В принципе, источник как источник, однако дочитайте статью на википедии до раздела «Критика» и поймите, что нет ничего совершенного в мире прогнозов и оценок. С другой стороны, ставка LIBOR тоже, как оказалось, манипулируема (упражнение: прочитайте, как она формируется, а лучше – как формировалась раньше, и оцените «порог» сговора), но пользуются все. В общем, использование квадранта – шаг скорее разумный, чем нет. Но в трактовке IT-директором трудов уважаемой консультационной компании в подавляющем большинстве случаев начинаются странности.

Первая странность состоит в том, что изначально IT-директора рассматривают только те компании, которые находятся в правом верхнем углу, то есть те компании, которые и сейчас лидеры, и продукт у них самый хороший. Вроде бы всё правильно, но иногда в этом углу могут оказаться только 1-2 компании, причем среди них может не быть компаний «на слуху». Ну, потому что аналитики так подумали в этом году. Примеры квадрантов.

№ 1. Счастье IT-директора (квадрант посвящен системам хранения данных).

Счастье – потому, что EMC – это была реально дорогая штука (в 2016 году её купил Dell, сейчас сказать про ценовую политику ничего не могу). Очевидно, что между «дорого» и «очень дорого» выберут просто «дорого» (за исключением случаев сильно нагруженного биллинга), при этом можно провести «честный» конкурс.

№ 2. Абсолютное счастье IT-Директора.

Ну, тут всё очевидно. Есть явный лидер, закупаем только у него. Но такие квадранты бывают очень редко.

№3. Незадачка для IT-директора. Иногда квадранты дают сбой с точки зрения подхода. 

Если честно, специально в картинках такой искал, это самый первый квадрант по IoT. Большая редкость, привел для примера.

№4. Ужас IT-директора. Квадрант по СУБД.

Ужас – потому, что явно можно провести очень правильный конкурс без всяких кавычек.

Вторая странность, причем очень важная – перечень лидеров немного модифицируется. Вариантов, очевидно, два:

  • исключить какие-то компании. Например, если компаний 11, как в примере №4, то можно оставить 3. В отличие от следующего шага, ни к каким балльным оценкам не прибегают и основываются на суждении. Примеры обоснований:
    • это «принципиально дороже». Тезис сомнителен (см. отличие 3 во введении), но иногда имеет право на существование (см. пример 1 из этого раздела);
    • плохо представлено в России. Если честно, то при наличии русификации и хотя бы нескольких проектов, исключение уже представляется нецелесообразным;
    • отсутствие поддержки какой-либо технологии. Увы, даже у профессионалов с опытом бывают разные независимые мнения, нужны ли такие технологии либо же нет. Из примера №4 – СУБД у Amazon – только в облаке, очевидно, что нужно вычеркнуть. Но, этот пример не показателен, уверен, специалисты для того же примера найдут, почему нужно допустить Microsoft и не допустить Oracle либо же наоборот;
    • отсутствие лицензии/аккредитации/свидетельства. Иногда оказывается, что нужно (требования государства). Особенно для IT-директора здорово, если конкретный набор требуемых бумажек есть только у 1-2 потенциальных участников;
  • добавить какие-то компании. Уверяю Вас, что если такие компании добавлены, то это неспроста. Примеры обоснований:
    • российские компании (оно же – «импортозамещение»). Понятное дело, что для систем бухгалтерского и налогового учета это разумно, для всего остального – если не в государственной структуре, то не очень;
    • компании со значительным опытом в отрасли.

В общем, требуемые 2-4 компании набрать несложно.

Из веселых примеров из жизни:

  • квадрант оказался позапозапрошлогодним. Со старой работы директора по IT. Ну, а зачем презентации перерисовывать, если с того момента продукт и поставщик не изменились?;
  • к мировым лидерам добавлена компания на упрощенке…

Если квадранта Гартнера нет, то IT-шники не заморачиваются и переходят сразу к шагу 2. Встречается вариант, когда используют какой-нибудь рейтинг и выбирают из него условные №№ 2, 3, 5 и 9, но это редкость, потому что до шага 2 можно вполне «допустить» и всех.

Итак, мы определили «исходя из мировых тенденций» круг потенциальных поставщиков, поэтому переходим на

Шаг 2. Определение необходимого вендора.

Задача этого шага – выбрать конкретного вендора/производителя. Это делается за счет балльной оценки. Останавливаться подробнее не буду, главное – критериев должно быть побольше, максимальные и минимальные оценки должны быть у всех потенциальных вендоров, критерий цены не является определяющим. В общем всё как всегда (см. книжку со стр. 187). Количество критериев может быть различным, оценки ставятся лично IT-директором, реже встречаются оценки на основании ангажированных обзоров рынка. Особенность именно в этом случае – у директора по IT, как правило, нет профессионального оппонента, и он легко переговорит всех обывателей. Поэтому если и вступать в дискуссию – обеспечьте равные условия, то есть оппонировать должен кто-то независимый от директора по IT и столь же профессиональный, что редко бывает внутри компании. 

Из веселых примеров из жизни:

  • компания-лидер рынка была «забанена» по критерию «Опыт сотрудников организации». В переносном смысле – не нужно допускать 1С, потому что бухгалтерия раньше работала на самописе;
  • в течение четырех месяцев с момента первого рассмотрения до момента финального рассмотрения вендоры по балльной оценке одного и того же директора по IT выстроились в строго противоположном порядке;
  • если помните, что в качестве варианта «дополнения» квадранта Гартнера была компания на упрощенке. Думаю, что Вы уже поняли, кто уверенно обошел всех мировых лидеров по балльной оценке директора по IT… Не смогли разглядеть аналитики Gartner…

Собственно, задача этапа выполнена – мы выбрали конкретный продукт.

Шаг 3. Проведение закупочной процедуры.

Задача этого шага – выбрать «правильного» контрагента.

Начнем с технического задания. Скорее всего, его будет писать непосредственно поставщик. Соответственно, всё формирование ТЗ – это детальнейшее переписывание технических характеристик с тщательным исключением упоминаний торговой марки. Иногда добавляя «не менее» или «не более» перед параметрами, временами путаясь между ними (ну, как в ТЗ на микрокалькулятор написать линейные размеры «не менее, чем»).

Встречаются случаи, когда на формирование ТЗ привлекается отдельный подрядчик. Вариант имеет право на существование, но всегда есть риск получить ТЗ с закладками, особенно если подрядчик готов «сделать бесплатно». Исключение – привлечение на постановку задачи консультанта по управлению с последующей автоматизацией системным интегратором. Но выбор должен осуществляться независимыми подразделениями (условно, постановка задачи – маркетологом/финансистом, интегратора – директором по IT) и с сохранением конкуренции.

Отдельная тема, когда мы выбираем подрядчика на что-то с неявным результатом. Особенности при закупке ПО – мы не знаем, сколько будет стоить разработка, если нет четкого ТЗ. При разработке ПО нет попытки сделать «под ключ» и оценивается стоимость нормочаса. Даже на примере внутреннего аудита: я для анализа конкурса возьму 4 часа (и найду большинство «закладок»), кто-то возьмет 40 часов. Как думаете, кто победит при стоимости нормочаса в 4 раза дороже? Очевидно, не я….

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

Если отпустить формирование ТЗ на самотек, то требуемый «результат» будет достигнут независимо от количества участников. Из веселого на этом этапе – вся поставка была разбита на три лота: оборудование (90% от контракта), СМР (5% от контракта) и ПО к оборудованию (5% от контракта). За беспокойство «спойлеру» дали право поставить программное обеспечение. А по 223-ФЗ признать закупку несостоявшейся затруднительно, а у нас по каждому пункту – 2 участника…

Как бороться.

Рекомендации очевидны из вышеприведенного. Главное действие внутреннего контролера, не важно кто им выступает – не дать пройти первые два шага. Потому что всё решено уже до третьего шага. Как сохранить мультивариантность до проведения конкурса:

  • из квадранта Гартнера нужно выбрать не менее трех лучших, устраивающих по всем параметрам. Если их нет в правом верхнем углу – добавить из других. Лучше – максимум, если 10 будут потенциально подходить – значит, пусть остается 10;
  • никаких промежуточных балльных оценок. Аргумент прост: мы что, оцениваем лучше признанных во всем мире аналитиков?;
  • формирование ТЗ должно быть независимым от поставщиков. Перед объявлением закупочной процедуры необходимо уточнить у максимального количества потенциальных участников, готовы ли они участвовать при данном ТЗ. Кстати, если кто-то из поставщиков вызовется написать – в принципе, не страшно, потому что независимость будет обеспечена. Еще интересно видеть лицо автора после описанной контрольной процедуры… 

Дополнительно: если Вам предстоит «большой» проект по разработке какой-либо информационной системы – приоритетным должен стать вариант создания собственного подразделения по разработке. Дешевле будет. В ходе работ можно привлечь и аутсорсинг, но на не очень большой и очень конкретный объем работ.

Детальные рекомендации по чтению ТЗ, если внутренний контроль/аудит мониторит деятельность только на этапе закупок — часть 1 и часть 2. Кстати, не такой плохой вариант, потому что на шаге 1 могут не поверить… А когда закупочная документация готова, попытки плохих дел становятся более очевидными, и тест остается только один (опрос потенциальных участников).  

Результат «правильных» действий – снижение начальной максимальной цены, рассчитанной директором по IT, от 25 до 60+ процентов. Я это называю «пытались своровать», но лично за руку не ловил, поэтому давайте говорить о потенциальной экономии. Шаги несложные, под силу начинающему внутреннему аудитору, пригодны ко всем компаниям, поэтому очень рекомендую.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.