Заменить ваши программы или связать их?

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

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

Что на самом деле идёт не так?

Не программы. Каждая обычно неплохо делает свою работу: Tally хорошо ведёт учёт, на Shopify получается хороший магазин, а в WhatsApp ваши клиенты и так сидят. Проведите утро там, где принимают заказы, и у проблемы появится форма, всегда одна и та же. Она живёт в ручных переносах.

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

Как понять, какой случай у вас?

Посчитайте ручные переносы. На это уйдёт одно ваше утро, и мы для этого не нужны.

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

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

Теперь задайте каждой строке один вопрос: могла бы это сделать машина, если бы две системы умели общаться? Для большинства строк в большинстве списков ответ «да», и это задача связи. Замена здесь ни при чём: вы купили бы новое место, где набирать то же самое. Ответ «нет» бывает только тогда, когда набираемое вообще не может храниться в принимающей системе. Это тот узкий случай, когда замену действительно стоит обсуждать.

Когда правильный ответ в замене?

Три проверки. Система должна явно провалить одну из них, прежде чем замену можно честно рекомендовать.

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

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

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

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

Почему вам обычно советуют заменить?

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

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

На чём настаивать, если вы выбираете связь?

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

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

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

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

А если связали, а всё равно не так?

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

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

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