239. Мы не первые, кто это придумал
Я довольно часто говорю клиентам, что готовых решений именно под них не существует. Не, я не особо люблю изобретать велосипеды. Просто готовое решение почти всегда оказывается готовым для кого-то другого.
🤘 И почти каждый раз я слышу один и тот же вполне логичный ответ. Мол, мы же не первые, кто продаёт оборудование. Не первые, кто принимает заказы через интернет, работает с дилерами, поставщиками или торговыми ботами. Наверняка кто-то всё это уже сделал. Покажите нам готовый вариант, а мы немного подстроим его под себя.
Логика понятная. Если компании занимаются примерно одним и тем же, то и процессы у них должны быть примерно одинаковыми. Логично же.
⚡️ Но на практике одинаковыми они оказываются примерно до второго вопроса.
Например, в одной компании заказ появляется сразу после заявки клиента. В другой — только после оплаты. В третьей менеджер сначала должен получить подтверждение склада, проверить лимит и зачем-то написать финдиректору в личку. Ну вот так вот устроено.
Где-то скидку согласует руководитель. Где-то она рассчитывается автоматически. А где-то формально её вообще не нужно согласовывать, но бухгалтерия всё равно потом приходит и спрашивает, какого хера здесь произошло.
Снаружи компании действительно похожи. Они продают одинаковые товары примерно одним и тем же клиентам. Но внутри у них разные люди, зоны ответственности, исключения, договорённости и привычки, которые никто никогда не записывал.
❗️ И весь этот опыт уже зашит в готовое решение.
Поэтому его адаптация часто превращается в довольно тухлую затею:
〰 Переименовали статус и перестала работать автоматизация. 〰 Убрали ненужный этап и сломался отчёт. 〰 Поменяли ответственного и выяснилось, что на нём держались ещё три процесса, о которых никто не знал.
В итоге чужую систему приходится сначала долго разбирать, потом аккуратно вычищать из неё чужую компанию и только после этого пытаться встроить свою.
Я не против готовых решений. В них можно брать отдельные механики, структуру, интерфейсы и нормальные идеи. Я против покупки чужой сложности под видом экономии.
Потому что нередко дешевле собрать небольшой рабочий блок с нуля. Сделать MVP, запустить его на реальных задачах, посмотреть, где люди начинают обходить систему, какие исключения возникают и чего действительно не хватает. А уже потом развивать решение на основании фактов, а не предположений о том, как здесь всё должно работать.
Недавно мне попалась статья про удалёнку. Да, опять. Но главная мысль там гораздо шире. Мол, никакая организационная модель не работает отдельно от контекста.
Нельзя перенести правила, инструменты и внешнюю форму, не перенеся вместе с ними людей, отношения, зоны ответственности и способ принятия решений.
❗️ С автоматизацией происходит ровно то же самое.
Готовые решения полезны "на посмотреть". В них можно найти хорошие идеи и ошибки, которые уже совершил кто-то другой. Но принимать чужую систему за готовый ответ на свою задачу всё-таки не стоит.
Вы действительно не первые, кто это придумал.
Просто те, кто придумал раньше, собирали решение под свою компанию. Не под вашу.
@M3ybeev
