Четыре года вели складской учёт в Excel — где в итоге рвануло и во сколько это обошлось?

Мы в автозапчастях наступили на те же грабли при номенклатуре в 600 позиций. Из-за съехавшей строчки продали 30 несуществующих комплектов сцепления — получили 9 200 USD штрафов и растеряли клиентов. Перешли на облачную складскую систему, и процент ошибок при сборке упал почти до нуля. Лицензия обходится в 3 000 USD в год — это даже не треть того, что мы слили за один тот факап.

Таблицы — это инструмент для расчетов, а не реляционная база данных. В БД два человека не могут одновременно перезаписать одну и ту же запись: ставится блокировка или очередь. А в таблице тот, кто сохранил последним, просто затирает чужие данные. Учет остатков — процесс многопользовательский, так что рано или поздно у вас должно было бомбануть. Сочувствую, но хорошо хоть усвоили урок до того, как компания обанкротилась.

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

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

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

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

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

Слежу за темой. Главное не цифра, а то, на основе чего она получена.

Я бы пошел этим путем.

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

Я думаю иначе. короче прежде чем принимать решение посмотрите, какие данные у вас есть.

Как думаете, это сработает в любом масштабе? Остановить рост и перевести дух — тоже стратегия, но об этом молчат.

Больше всего времени у нас уходило на то, что было непонятно, кто принимает решения. Интересно, есть ли те, кто делает иначе.

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

Я бы пошел этим путем.

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

исправьте если я ошибаюсь.

Мне тоже интересно.

Хочу задать вопрос. Если не зафиксировать это письменно с самого начала, потом возникнут споры.

Те, кто начинает бизнес во второй раз, не повторяют старых ошибок, но находят новые. Удачи.

именнно так. не менее важно когда принято решение о закрытии, чем само решение.

прибыль на бумаге, но нет денег на счету — очень частая ситуация. я бы пошел этим путем.

Очень актуальная тема. Главное не цифра а то на основе чего она получена.

Как только вы зависите от одного клиента цену диктуете уже не вы. Исправьте, если я ошибаюсь.

У нас так же. Прибыль на бумаге, но нет денег на счету — очень частая ситуация.

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