Закупки как сервис
Всем привет!
Меня зовут Алексей, и я работаю в компании 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. Это ещё и глубокое понимание особенностей собственной инфраструктуры, чтобы коллеги из эксплуатации получили нужное качество сервиса без звёздочек и сносок мелким шрифтом. Это, наконец, понимание юридических и финансовых «правил игры», потому что вовремя подмеченная неточность в договоре или бланке заказа может сэкономить неделю-другую времени на согласованиях.
В общем, это весело!
