Техподдержка WMS или имитация: как защитить склад и бизнес от простоев

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

Речь пойдёт исключительно о поддержке системы управления складом (WMS). Сопровождение серверной инфраструктуры, администрирование баз данных, обслуживание операционных систем и другие инфраструктурные задачи относятся к отдельным видам услуг и требуют самостоятельного рассмотрения.

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

Без чёткого регламента складских процессов сложно доказать, что ошибка произошла по вине вендора. Поэтому уровень сервиса напрямую зависит от качества вашей проектной документации.

Если вы сначала тратите часы или дни на то, чтобы разобраться, что произошло, а потом ещё столько же на закрытие тикета, эффективной такую поддержку назвать сложно.

И ещё один момент, о котором часто забывают: инциденты происходят не только по вине системы или поставщика, но и по вине пользователя.

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

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

Прежде чем идти дальше, важно развести два понятия, которые на практике постоянно смешивают, и из-за этого ломаются и ожидания, и договоры.

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

Доработка в полном смысле слова – это работа. Она выполняется по фиксированной цене на основании предварительной оценки и предполагает конкретный, заранее описанный результат: новая функция, отчёт, изменение логики, переданные в виде пакета. Здесь сначала идёт описание, потом оценка трудозатрат, потом реализация, тестирование и передача.

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

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

Граница простая: то, что имеет описанный результат и оценку, – работа; то, что направлено на устранение остановки процесса здесь и сейчас, – услуга.

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

Теперь пройдёмся по типовым обещаниям, которые вы встречаете в предложениях, и посмотрим, что за ними стоит.

Само по себе это хорошо и нормально. Единственный нюанс: круглосуточная поддержка не может быть дешёвой. Дешёвая линия 24/7 гарантирует быстрый ответ, но не быстрое решение. Здесь критично смотреть, на какие этапы делится процесс.

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

Корень проблемы – отсутствие гарантированных специалистов. Если поставщик не выделяет инженеров с зафиксированными за клиентом часами в дневное и ночное время, он экономит на штате в расчёте на то, что обращений будет мало. В такой модели один оператор тянет время и при необходимости дёргает разработчиков. А идеальный шторм рано или поздно случается.

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

Считаем. В поддержке не могут сидеть люди, которые знают мало: их задача – очень быстро понять и устранить почти любую проблему, тем более на открытой системе, где изменения мог внести и сам заказчик. Примем зарплату такого специалиста за условные 200 тысяч рублей на руки. С налогами и взносами это около 260 тысяч. Накладные расходы возьмём по минимуму – ×1,3 (хотя отраслевой ориентир скорее 1,5–1,75: сотрудника нужно обеспечить техникой, кадровым и юридическим сопровождением, соблюдением норм).

Даже с этим скромным коэффициентом себестоимость часа приближается к 3 тысячам рублей. Добавим налог на прибыль и минимальную маржу – и реальная стоимость 60 часов оказывается в диапазоне 160–200 тысяч рублей. Значит, при цене 80 тысяч порог себестоимости просто не пройден: уровень обслуживающего специалиста стремится к нулю.

Вот здесь стоит насторожиться – но не потому, что SLA плох, а потому, что за этой формулировкой чаще всего скрывается совсем не то, что думает заказчик. Разберём отдельно.

Главный вопрос к любому SLA: к какому параметру он привязан. Это принципиально.

Если SLA в 100% привязан ко времени реакции – например, один час, – то это не тот SLA, о котором мечтает заказчик, желающий получить бесперебойную систему. При увеличении времени реакции стоимость услуги может снижаться, но рабочую систему вы при этом не получаете: вы привязываетесь к операционному параметру, который сам по себе ничего не гарантирует.

Время разрешения тоже неоднозначно, потому что «решить» можно по-разному. Отсюда популярные в договорах workaround’ы.

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

Дальше – классификация проблем. Часто их делят на критичные (разрешить, скажем, за 4 часа), некритичные (8 рабочих часов) и низкоприоритетные (32 часа – это уже четыре рабочих дня). И привязывают категории к процессам: приёмка критична, инвентаризация – нет. Но на складе критичным может оказаться даже своевременное формирование отчёта, поэтому слепо полагаться на такую классификацию не стоит.

Наконец, любимый термин – SLA на доступность системы. Звучит прекрасно, но разберём, из чего он складывается. Берём 24 часа × 7 дней × 4 недели, получаем «100% времени», обещают 99% – значит, 1% система может не работать. И тут всё упирается в определение «неработающей системы». База доступна – система работает? Сервер приложений и веб-интерфейс доступны, а интерфейс терминала нет – это доступность или нет? А если те же операции можно повторить через веб — это уже workaround?

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

Аккуратный вывод: SLA в том виде, в каком его чаще всего продают на рынке, формально защищает скорее поставщика, чем склад. Но это не порок самого инструмента – это следствие того, как его собирают и интерпретируют.

Сам по себе SLA – это рабочий и проверенный механизм управления качеством сервиса. Вопрос не в нём, а в том, как он сформулирован, согласован и встроен в договорные отношения между сторонами.

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

Их нужно объединять в одну конструкцию.

Работающая модель выглядит так:

• База — инцидентная поддержка с гарантированно приобретёнными часами. Заказчик покупает конкретный объём – скажем, 60 часов в месяц одного специалиста и сколько-то часов другого, — и эти часы распределяются по рабочим дням (условно «два часа в день гарантированно с таким-то специалистом»). Это и есть тот самый зарезервированный ресурс, который обеспечивает решение «здесь и сейчас», а не ожидание свободного инженера. Когда специалисты в доступе, понятно и объёмно-календарное планирование: за какое время заявки будут закрыты.
• SLA — поверх этой базы, как требования к процессам поддержки. То есть SLA здесь не продаёт вам абстрактную «работающую систему» сам по себе, а выполняет роль предохранителя: если согласованные параметры (время реакции, срок реализации, доступность) нарушены, стоимость обслуживания за период снижается.

В такой связке исчезает большинство ловушек, которые я описал выше. Ресурс гарантирован часами, поэтому простой не зависит от того, занят ли сейчас инженер на другом клиенте. Качество гарантировано SLA-параметрами, поэтому поставщику невыгодно тянуть время и злоупотреблять workaround’ами. А заказчик понимает, за что именно платит: за конкретный объём конкретного уровня специалистов, а не за формулировку «у нас всё будет хорошо».

Универсального шаблона здесь нет. У одних заказчиков SLA привязан к технической производительности и общим параметрам, у других – к возможности выполнять конкретные бизнес-процессы, и в каждом случае всплывают свои нюансы (особенно если заказчик что-то перенастроил сам – тогда логично сначала вернуться в исходную точку). Но именно объединение «гарантированные часы + SLA» я считаю наиболее зрелым и взаимовыгодным подходом из доступных сегодня.

Важно делить гарантийную поддержку и платное сопровождение. Гарантийная поддержка — это то, за что вы, как правило, уже заплатили: она входит в штатную комплектацию продукта и имеет заданные, обычно более «лайтовые» параметры (никто не продаёт гарантию в режиме 24/7 с реакцией 30 минут на годы – иначе продукт стоил бы космических денег). Логика понятна: к моменту гарантийного периода заказчик прошёл функциональную сдачу и опытную эксплуатацию, всё протестировал, и возникающие вопросы можно положить на конкретное описание в техническом решении.

Здесь же кроется одна из самых частых проблем – невозможность смоделировать заявку. Специалист заказчика подаёт обращение «как гарантийное», но не может сослаться на то, почему оно гарантийное: «я так чувствую». А это зависит не только от человека, но и от документации. Если в проектных документах написано, как должна работать система и к чему приводит та или иная последовательность действий, вы с очень высокой вероятностью «приземлите» проблему на это описание. Если не написано или написано крупными мазками – сделать это почти невозможно.

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

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

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

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

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

Минимальный чек-лист:

• К каким параметрам привязан SLA – к реакции, времени реализации или доступности.
• Есть ли гарантированный ресурс: зафиксированные за вами часы и уровень специалистов, доступ к инженерам и консультантам напрямую, без бесконечной первой линии.
• Где проходит граница услуги и работы: что закрывается в рамках поддержки, а что идёт отдельной доработкой с описанием, оценкой и фиксированной ценой.
• Есть ли тестовый контур и пакетный перенос, и как устроены очереди заявок и объёмно-календарное планирование часов.

Идеальной поддержки за минимальные деньги не существует, и ошибки неизбежны у любого поставщика – важно не выяснять «кто виноват», а быстро решать проблему, имея гарантированный ресурс и прозрачные правила взаимодействия.