Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 11
Двадцать лет в экосистеме 1С и не знать. Может у вас было очень специфичный продукт?
Просто все это смахивает на пиар готовых решений от 1С.
как человек, который на всякие доработки 1с и коробочные решения смотрит со стороны бизнеса, то данный текст, если не нейрослоп и реклама очередного коробочного "суперрешения", и если принять логику автора, просто адски беграмотный.
1. Готовые решения ВСЕГДА ориентированы на САМЫЙ ОБЩИЙ СЛУЧАЙ. Если что-то выходит за рамки самого общего, то сразу начинается боль, потому что менять процессы под информационные системы в значительном числе случаев невозможно. Пример - например, сложные топологии склада настойчиво требуют дописывать или отказываться от ряда функционала, а с физической топологией ничего не сделаешь - склад перестраивать это уже не миллионы, а миллиарды. Ковырять все равно придется, но предварительно заплатив за полет на Канары коллектива разработчиков этого самого "готового" коробочного продукта. Управленцы это часто не понимают. Но я не видел ни одной коробки, которая не дорабатывалась бы.
2. В 1С пишут не "с нуля" обычно, а на базе готовых конфигураций. А это сильно проще, чем кажется, потому что многие элементы уже есть. Например, неоднократно видел рабочие, и относительно неплохо работающие самописные WMS-модули, разработанные на коробке УТ. К вопросу, на мой взгляд, неплохое решение, так как позволяет бесшовно связать склад и продажи, снижая риски. В УТ есть адресное хранение, потому дописать там относительно немного, если знать как.
3. Цена готовых решений бывает запредельна. Коробка WMS по стоимости- это минимум год-полтора работы очень дорогого разработчика, у меня же были примеры, и когда разработчик на поддержке писал самописный модуль (то есть, за ту же зарплату, которую ему все равно платят за то, что админит, дописывает мелкий функционал и отчетность), и когда дописали нужный функционал за полгода работы отдельным проектом. Плюс поддержка готовых решений бывает, тянет деньги похлеще любого пылесоса. Например, Директум тот же - гораздо дешевле нанимать отдельного разработчика в случае проблем, чем оплачивать поддержку при эксплуатационных проблемах.
4. Риски у самописных продуктов есть. Они, во-первых, часто плохо архитектурно продуманы, так как требования бизнеса перманентно наслаиваются на первоначальную архитектуру, и выдерживать парадигму становится трудно. Во-вторых, плохо документированы. Кроме bus-фактора, они становятся хорошей кормушкой для разработчиков, которые кормят их годам. Но преимущества это перекрывают - не бизнес подстраивается под инструмент, а инструмент под бизнес.
И вообще, агитацию за непременно готовые решения в любом случае без учета всего вышесказанного я воспринимаю как косвенный признак откатов. Потому что коробочные решения в массе своей используются на 50, от силы 60%, прям классика - куплен Битрикс, а в Битриксе на задачи никто внимания не обращает, сроки не отслеживаются, про кооперацию вообще никто ни сном ни духом, в чатиках молчание, используется как звонилка, а половина сотрудников вообще не входят туда никогда.
Давайте я вам тогда по пунктам и отвечу:
1) Согласна, есть случаи когда уместно взять готовое и есть наоборот. Но, к примеру, правила переносов, писать под каждого клиента не всегда имеет смысл.
2) Опять же, смотря какие задачи вы перед этим модулем ставите и в какой компании эта задача появилась.
3) Т.е. до момента возникновения потребности в модуле у вас разработчик чем-то занимался, потом возникла потребность и его переключили на разработку, а остальные-то задачи кто за него делал? Или все мелкие задачи он делать перестал?
4) Риск есть всегда, когда сам разработал, когда купил готовое, когда заказал у франча.
Статья опубликована, как "мнение". Мое мнение и мой жизненный опыт показал, что в 80% задачи управленца можно решить готовыми решениями и не нужно изобретать велосипед. Вы же мне в пример приводите модуль WMS, что все-таки больше в автоматизацию работы склада, а не управленца и его работы. Возможно мне стоило уточнить по тексту, что я больше про рабочие столы менеджеров, дашборды, расчет кпи, работу в мессенджерах, учет про проектам и тп.
Хотя, входящие задачи во франчах от клиентов тоже можно было решить проще и быстрее, но я рассуждала как комментаторы выше.
Вы меня прямо удивили, я почему-то всегда думал, что внедрение начинается именно с подгонки готового решения. Ну по крайней мере фундамент БУ точно можно взять и на его основе создать что-то свое. Ну хорошо, а БСП как же? Тоже не использовали?
Использовали.
А где вы брали/берете эти решения? Делаете свой банк внутри компании?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ошибки, которые можно было не совершать