Закупки как сервис

January 31, 2022 by snakeslair

Всем привет!

Меня зовут Алексей, и я работаю  в компании ecommpay IT. Мы пишем и эксплуатируем ПО для эквайринга и процессинга карточных платежей. Если совсем по-простому – мы делаем так, чтобы оплачивать товары в Интернете было удобно, быстро и безопасно.

Я было хотел написать, что в компании я решаю проблемы, как Мистер Вульф из известного фильма, но вовремя вспомнил недавнюю статью и подкаст Василия Пантюхина, и решил, что надо быть скромнее.

Пусть это будет Максми Поташёв Александр Друзь.

Почему? потому что чаще всего я по работе отвечаю на три простых вопроса:

Что из оборудования или софта было заказано в текущему/прошлом месяце/квартале? Что ещё можно/нужно заказать в этом квартале, чтобы уложиться в бюджет?
Где деньги сейчас находится заказанное оборудование? А что есть на складе?
Когда приедет/будет оплачено то, что заказали?

Кому-то может показаться, что это абсолютно скучная бумажная работа, и инженерам тут делать нечего, но это будет только долей правды 😉

disclaimer: “В нашей жизни не всё, всегда и везде, а кое-что, иногда и местами” (с) Максим Дорофеев.
Всё ниженаписанное можно и нужно считать личным мнением автора, не претендующим на истину в последней инстанции, и даже на полноценное исследование. Все персонажи вымышленны, все совпадения случайны.

Кто обычно занимается закупками техники и софта, и какие с этим есть проблемы

В не-ИТ компаниях обычно это офисный сисадмин (ну или начальник ИТ-отдела, если таковой вообще есть).

С ИТ-компаниями всё сложнее. Я видел как варианты “офисного сисадмина на максималках”, когда человек покупал в т.ч. и железо для ДЦ, и софт, и ноутбуки для сотрудников. Если компания большая, то в ней может быть целый отдел, который занимается закупками (причём всего – от скрепок до СХД). В маленьких компаниях со множеством команд “живущих по эджайлу”, вообще у каждой может быть свой бюджет и своя карта для оплаты (и хорошо, если это карта корпоративная, а не личная).

Ну и разумеется, не последнюю роль в закупках играет ИТ-директор, который отвечает за немаленький, обычно, бюджет, а значит, должен следить за наиболее важными/крупными затратами лично.

Я встречал ситуацию, когда каждый сисадмин в компании мог практически без апрува заказывать серверы для своей команды через письмо в sales-отдел хостинга. Помимо кучи железа, которое не пойми для чего было заказано, и как использовалось, довольно часто возникала ситуация, когда сервер выдали, а кто, когда и зачем его заказал – непонятно. Или сервер выдали – и его тут же по ошибке или намеренно “подрезали” более расторопные коллеги. Отдельно стоит отметить чатик в скайпе на 20+ человек, в котором сидели представители хостинга и все сисадмины, и где одним из самых частых вопросов было “а кто заказывал сервер по тикету xxxxx?”

Но кто бы это ни был, частенько бывает так, что управление расходами на ИТ-инфраструктуру превращается в кошмар:

• у офисного сисадмина часто не хватает квалификации и времени (потому что обычных офисных задач с него никто не снимал);
• у директора ИТ (CIO/CTO/CITO, подставить нужное) и так дел невпроворот, в итоге задачи либо “падают на пол”, либо рандомно скидываются кому-то из его подчинённых, (обычно, когда все сроки уже прошли), либо просто сжирают и без того конечное рабочее время и силы;
• у отдела закупок своё (отличное от ИТ) начальство, свои KPI и свой взгляд на то, как должен быть организован процесс. В идеальном мире сотрудники этого отдела имеют некоторое представление о том, что они покупают, и плотно общаются с командами-заказчиками, но так происходит не всегда. Да и выделенный отдел – это, банально, дорого;
• если оплатой занимаются тимлиды команд или отдельные инициативные сотрудники, то отслеживание этого – мрак, ужас, и много-много новопассита для бухгалтерии. Левые личные карты, учётки на личные почты на гмыле, потеря информации при увольнениях/переходах и т.д. и т.п. Поиск концов каждый раз превращается в увлекательный квест.

Почему так происходит? Айтишники не очень хотят возиться с бумажками, счетами и отчётностью, да и вообще не очень любят общаться с менеджерами. У них (как правило) есть резон побыстрее включить нужный сервис, протестировать, и, если всё ок – запустить в продакшен. Меньше всего им хочется отвечать на письма и звонки от продаванов и обсуждать детали договора с бухгалтерией и юристами.

Процесс управления работой с поставщиками называется на Западе Supplier relationships management, а если по-модному – FinOPS. Когда я только начинал этим заниматься года три с половиной назад, ни про каких FinOPS я не знал, поэтому для названия команды выбрал именно Supplier relations. В англоязычных статьях упирают на то, что FinOPS оптимизируют только облачные расходы (читай: умеют пользоваться Cost calculator), но для простоты здесь я буду считать, что это одно и то же.

Кто такие FinOPS

Supplier relations managers, (или FinOPS) – это люди, которые не только занимаются закупками IT-сервисов, лицензий и оборудования, но и налаживают связь между заказчиком (т.е. компанией, где они работают) и внешними поставщиками. Чтобы не было, как на известной картинке:

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

Ещё раньше, даже до поиска подходящего поставщика, нужно заняться переводом хотелок заказчика (бизнеса или команды) в нечто измеримое: ядра, гигабайты, стойки, киловатты и т.д. И хорошо если заказчиком является свой родной ИТ-отдел, (хотя и тут бывает не всё радужно).

Например, задача найти “хостинг в Бразилии” может на самом деле означать как то, что нужно проработать вариант организации полноценного PoP с размещением оборудования и подключением провайдеров, так и то, что для тестовых целей нужно поднять пару виртуалок в AWS в соответствующем регионе. Причём, реальные требования могут меняться в процессе жизни всего проекта в обе стороны.

Следующим шагом является поиск подходящего поставщика (в гугле на рынке или через знакомых). При этом у каждого из них свои условия оплаты и гарантии (часто с привлечением партнёров), свои нюансы вроде SLA со звёздочкой и примечанием мелким шрифтом на пятьдесят последней странице договора, и ещё десяток различных мелочей, часть из которых проходит по разряду “так исторически сложилось” и ни в каких документах не отражается. И чем понятнее (на языке поставщика!) будет сформулирован запрос, тем меньше отличий будет между ожиданием и реальностью. (и это происходит, в хорошем сценарии, ещё до подписания договора, на этапе предварительного знакомства). Ну и опять же, в каждом крупном заказе есть множество различных нюансов: например, одни провайдеры делают резервирование VPN-каналов по-умолчанию, другие хотят за это дополнительных денег. Одни готовы подписаться на SLA по latency, другие нет. Какой-нибудь Trusted Platform Module или дополнительная сетевая карта, как опция при заказе сервера, не стоят, практически, ничего, но если покупать их у того же поставщика отдельно, то влетят в копеечку – и таких нюансов просто море.

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

Ну и наконец после получения железки или лицензии есть “послепродажное обслуживание”, с которым тоже далеко не всегда всё бывает гладко, и приходится помогать коллегам решать различные вопросы, в т.ч. и самому общаться с техподдержкой (и её начальством), координировать возвраты по RMA и т.д.

Одна компания пользовалась весьма крупным публичным облаком для тестовых сред. Облако достаточно дешёвое, но его стабильность даже для этих целей оставляла желать, к тому же саппорт отвечал не то, чтобы быстро, а уж про решение проблем я вообще молчу. На звонке с аккаунт-менеджером тот заверил, что это неприемлемо, и он примет все меры… После чего исчез. Натурально, перестал отвечать на письма, а его личного номера у нас не было. Как вы думаете, что сделали FinOPS в этой ситуации?

С одной стороны, это куча бумажек, писем, звонков и новых знакомств практически ежедневно. Ты общаешься с партнёрами, юристами, бухглатерией и “внутренними заказчиками” по совершенно разным вопросам, начиная от причины появления НДС/VAT в очередном инвойсе и заканчивая порядком расположения плат расширения в сервере в зависимости от выбранной в конфигураторе опции razer extender. Нужно следить за рынком, новыми версиями железа и софта, новостями, которые могут повлиять на стратегию закупок (например, недавние остановки фабрик в Техасе могут привести к дефициту и увеличению сроков отгрузки, так что лучше какие-то позиции купить заранее). Не менее важно давать поставщикам обратную связь – не только по нынешним/прошедшим заказам, но и делиться планами на квартал/год.

Как-то мы ждали оборудование от одного очень важного партнёра для размещения в нашей стойке. Партнёр – очень крупная международная компания, поэтому для доставки нанял специального подрядчика, который уже общался с логистами и нами, как получателями груза. Примерно за день до предполагаемой даты доставки мне звонит представитель подрядчика и просит не принимать груз, потому что это оборудование отправили к нам по ошибке, а “правильное” отправят в другой день. Этот же партнёр отличился, заказав в датацентре кроссировку в нашу стойку без LoA (letter of authorization), т.е. без разрешения с нашей стороны. А т.к. кроссировку прокладывал ещё один подрядчик, то о том, что к нам собираются завести кабель, я узнал только от нашего аккаунт-менеджера, который запросил разрешение на доступ в нашу стойку инженеров ДЦ.

В подавляющем большинстве случаев, задачей любого поставщика (не важно, продукта или сервиса) является доставка пользователю счастья. В случае b2b счастье (оно же value) обычно выражается в удовлетворении некой потребности (как бы банально это ни звучало). Но проблема заключается в том, что далеко не всегда заказчик может сформулировать, а что же он, собственно, хочет. И тут FinOPS выступает в роли “переводчика”, причём в обе стороны. С одной стороны, он объясняет поставщикам в технических терминах (и со специфическими для поставщика деталями), что же именно хочет получить бизнес. Да, в идеальном мире это делает “админ или тимлид из ИТ отдела”, но… см выше про интровертную сущность инженеров и недостаток времени у руководителей.

С другой стороны, нужно перевести бравурные презентации пресейлов на технический язык, продраться сквозь бумажки (а вы знали, что английский канцелярит ничуть не лучше русского?), добавить известными “мелочами”, которые не пишутся в оферте, и внятно объяснить своим, что же именно нам хотят продать, но уже на понятном внутри языке.

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

Другой неочевидный момент – это экономия времени. Если у FinOPS есть крепкий технический бэкграунд, то многие вещи он может разруливать сам, не отвлекая коллег или руководителей. Составление оптимальных спек (учитывая особенности вендора или партнёра), общение с пресейлами и саппортом – зачастую, всё это гораздо удобнее решать именно им, т.к. именно у FinOPS есть под рукой и контекст задачи, и нужные контакты, и возможность ускорить решение вопроса за счёт личных знакомств.

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

Ещё был совершенно классический случай, когда две услуги от разных провайдеров “мамойклянус, независимые!” оказались в одном кабеле. Было неприятно.

С кем взаимодействуют FinOPS по работе

В больших (и очень больших) компаниях отдел закупок может быть централизованным. Но это немного не наш сценарий. Впрочем даже в этом случае FinOPS найдёт своё место либо в рамках этого отдела, либо…

Разумно выделять SR team (или FinOPS team) в рамках ИТ-отдела. Почему? потому что часто это основная точка расходов компании. Закупка железа, лицензий, сервисов – очень быстро расходы на ИТ становятся заметными (и очень заметными) для собственников, и ИТ-директору нужно очень хорошо и чётко не только объяснять, сколько и куда уже потратили, но и делать прогнозы (или составлять бюджет и его исполнять) на квартал, а то и год вперёд. Сюда же относятся управление лицензиями и общение с сервис-провайдерами – всё это забота ИТ, и FinOPS, как его части.

Одна из обычных историй – в пять часов вечера пятницы к тебе приходит представитель поставщика, и говорит, что хорошо бы оплатить вот этот инвойс до конца дня, а то резерв превратится в тыкву, и отгрузка пройдёт неизвестно когда. Далее начинается квест “подтверди закупку, найди бухгалтера и дождись платёжки” длиною в час. Платёжка была отправлена в 17:58, заказ был спасён.

Команда SR (FinOPS) может успешно работать (и работает) в связке с Ops и инфраструктурными командами (которые непосредственно занимаются эксплуатацией датацентров, сетевого и серверного железа), привлекая их экспертизу и помогая общаться с вендорским саппортом, начиная от помощи с эскалациями (когда проблема не решается в разумные сроки, и нужен живительный пендель; и заканчивая полным ведением тикета (как правило, общение с саппортом крупного вендора вялотекущее, но контекст всё равно нужно держать в голове. Плюс в случае RMA помогать с доставкой или организацией визита сервис-инженера).

Я встречал мнение, что быть технарём FinOPS не обязательно, ему главное бумажки вовремя перекладывать, эскалации писать и за оплатами следить. Но на своём опыте могу сказать. что именно FinOPS в таком случае не получится, а будет очередной “отдел закупок”, слабо понимающий, что за услуги он закупает.

Ещё одна типичная история – это постоянный анализ “выгодных предложений” от партнёров. Предложения бывают выгодные или не очень, своевременные и не совсем. Их первичным анализом занимается именно FinOPS, как “первая линия обороны”. Если же он просто будет бегать туда-сюда с вопросами, то какой в нём смысл?

Неочевидные нюансы работы и требования к FinOPS

Как я уже говорил выше, при оформлении сделки (подписании договора и/или выставлении инвойса) возникают различные неожиданные моменты, даже если мы говорим о 100% белых компаниях.

Сюда относится:

• юрисдикция сделки (по законодательству какой страны заключается соглашение);
• резидентами каких стран являются стороны сделки;
• по какому адресу необходимо отгрузить товар или предоставить услугу;
• валюта (RUR/USD/EUR – порой одна из сторон, например, не принимает платежи в USD, или наоборот, не может платить в USD без большого геморроя, предпочитая евро, сюда же платежи из России в пользу иностранных юр. лиц);
• налоги (в каждой стране свои приколы);
• сроки поставки и её стоимость;
• трансграничная торговля, санкции и ограничения регуляторов (и связанные с этим ограничения на поддержку, увеличение сроков поставки и т.д.);
• срок договора (расторгнуть его досрочно может быть очень дорого), SLA сервиса, и т.д. и т.п.

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

Например, некоторое время назад покупать софт в РФ было выгоднее, чем в Европе, потому что на него не начислялся НДС. С января, к сожалению, халява закончилась, и по этому поводу в конце 2020 года было достаточно жарко, т.к. нужно было успеть заказать/подписать/оплатить самые важные и дорогие позиции.

Что требуется от Supplier relations manager/FinOPS

• Разговорный английский. Это прямо must have и не обсуждается, если только ваша компания не общается сугубо с российскими поставщиками
• Разумная степень занудства.
• Не бояться разбираться с бумажками, огромным количеством почты и кучей разных сейлзов, часть из которых разговаривает по-английски хуже, чем вы (хотя по опыту, общаться с британцами и ирландцами тоже нелегко).
• Умение ориентироваться в 100500 различных сервисах, в части из них разбираться очень хорошо.
• Умение и желание находить нужных людей и добиваться от них того, что тебе нужно.
• Умение найти нужный сервис по очень примерному ТЗ, а заодно набросать MVP или задать правильные вопросы пресейлу (например, при выборе датацентра).
• Совершенно обязателен технический кругозор (а также желание его постоянно расширять), чтобы разговаривать на одном языке и со своими командами, и с вендорами/партнёрами.
• Умение держать в голове кучу вещей одновременно и помнить сроки, суммы и проценты (это бывает важно). Можно, конечно, обойтись каким-то аналогом CRM, но помнить всё равно нужно много (как минимум – как и где быстро найти нужную информацию).

Инструменты FinOPS

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

Уже после, когда поймёте, что вам нужно, можно будет поискать (или написать самим) соответствующие инструменты а-ля “CRM наоборот”.

Не надо недооценивать силу эксель-таблиц и усложнять что-то раньше времени.

Ну и конечно, мессенджеры становятся вашими лучшими друзьями. Причём почти все, включая довольно экзотические – потому что у всех партнёров разные предпочтения и корпоративные правила. В 2021 говорить про использование мессенджеров это, наверное, из разряда “советы Капитана Очевидность”, но нужно понимать, что у FinOPS это не опция, а суровая необходимость и бОльшая часть работы.

Заключение

Закупки в IT – это просто, как кататься на горящем велосипеде. Управление закупками в IT – это не только своевременная оплата счетов и бюджетирование. Это ещё и общение с партнёрами, коллегами и “просто так”, потому что никогда не знаешь, какая информация и какие знакомства тебе пригодятся завтра. Сегодня ты слушаешь байки об особенностях работы в арабских странах и думаешь “как хорошо, что мы там не работаем!”, а завтра ищешь партнёра для размещения там нового PoP. Это ещё и глубокое понимание особенностей собственной инфраструктуры, чтобы коллеги из эксплуатации получили нужное качество сервиса без звёздочек и сносок мелким шрифтом. Это, наконец, понимание юридических и финансовых “правил игры”, потому что вовремя подмеченная неточность в договоре или бланке заказа может сэкономить неделю-другую времени на согласованиях.

В общем, это весело!