Комментарии 139
Их нынешняя ERP его вообще не устраивала, так как не было контроля за кухней и доставщиками
Так может стоило более подробно разобраться и донастроить? Мне тоже не нравиться Linux/Windows/MacOS… Может не стоило убегать от проблем?)) И хочется услышать, что за система была изначально у знакомого? И по описанию то, что вы делали ну никак не ERP, скорее CRM
В общем, система получилась очень мощной, с большим количеством возможностей реализованных, и с ещё большим количеством заложенных.
В общем, сейчас у меня есть интересная, почти готовая, ERP система.
Там не хватает каких-то отчётов
ERP система ищет нового заказчика
"Огласите весь список пожалуйста", что же умеет в итоге система-то, чего не умеют другие? Почему интересная? Что значит почти готовая?
В целом мне кажется статья получилась скомканная. Я не понял прелестей ни Delphi, ни RAD studio, и не понял о чем система, почему же она "мощная".
Контроль за персоналом это уже точно ERP фича, да и логистика тоже.
Нет. ERP имеет весьма формализованное представление.
ERP = MRP I + MRP II + финансовый контур
MRP I — это специальный алгоритм управления запасами для производства
MRP II — Это управление производственными мощностями
То есть тут нет ни одного пункта из ERP,
Транспортная логистика, работа с персоналом не входят в ERP
ERP II = ERP + CRM
У вас часть CRM + HRM
MRP I — это специальный алгоритм управления запасами для производства
MRP II — Это управление производственными мощностями
То есть тут нет ни одного пункта из ERP,
Транспортная логистика, работа с персоналом не входят в ERP
ERP II = ERP + CRM
У вас часть CRM + HRM
Вся производственная мощность — это и есть персонал, которому надо говорить в какой момент что делать. Это распределение нагрузок и пр. И это именно ERP система. Естественно в архитектуру это заложено, но сейчас например нет одной из главных вещей — автоматическое распределение заказов по точкам с учётом текущей нагрузки и пробок. Так же и некоторых других.
Пока решались другие проблемы: например что заказ начинался делаться через 10 минут после поступления. А всего на приготовление и упаковку 20 мин.
Пока решались другие проблемы: например что заказ начинался делаться через 10 минут после поступления. А всего на приготовление и упаковку 20 мин.
И это именно ERP система.
Возможно у вас именно ERP и вы полностью повторили функциональность SAP R3, но почему вы в статье рассказывали исключительно только про CRM (работа с клиентами), HRM (работа с персоналом) и TMS (работа с доставкой)? Вам же подсказывают про MRP I и MRP II. Где ваши анализы сезонных продаж (с учетом праздников) и составление на их основе планов производства и закупки ингредиентов (закупите больше — увеличите затраты из-за просрочки неиспользованного; закупите меньше — получите недополученную прибыль и уменьшение лояльности покупателей)? Где ваши расчеты по заготовке полуфабрикатов (последний элемент для суши и пиццы вообще очень важен, так как эти классы продуктов компонуют из заготовок, срок жизни которых от пары часов до суток, а потом нужно буквально утилизировать «деньги»)?
Не хочу спорить кто что подразумевает под этой аббревиатурой. Исходная система заказчика имела куда более скромные возможности, но тоже носило гордое название Farfor ERP. Хотя по факту там только приём заказов, пара выгрузок, да десяток отчётов.
ERP в широком смысле — это управленческая стратегия. ERP-система — система, помогающая эту стратегию реализовать, как правило, без перехода в другие системы, но не обязательно. ERP-система может импортировать первичные данные из одних (например, фискальных) систем и экспортировать в другие (например, OLAP). Так же имеется тенденция выделять в отдельные системы (пускай и интегрированные с ERP) то, что обычно было их модулями/подсистемами. например CRM модули.
VolCh, не люблю цитировать википедию, но уж больно хорошо у них написано:
Вы начали писать все верно, по потом пошла какая-то вода: «как правило, но есть много исключений», «может импортировать, а может и не делать этого», «имеется тенденция»… Прямо как Гидромецентр со своими прогнозами: может дождь, может снег, может будет, может нет :)
По факту: главной идеей и целью концепции и программ ERP является рачительное управление производственными ресурсами. Именно из-за несоответствия описанного функционала к примененному термину ERP, я прицепился к автору. Про планировании закупок не было ни слова, как я уже упомянул выше. Так же ни слова не сказано даже о самом базовом — планировании самого производства. Где-то в комментариях автор упомянул, что там в его системе есть рецепты, но он про такой «очевидный» функционал просто не стал писать. Этого мало! Те же рецепты можно на листиках от руки написать и на стенках повесить. А должен быть как минимум анализ потребностей кухни на основе уже собранных заказов (плюс прогнозируемые заказы на базе собранной в прошедшие периоды статистики), что бы завхоз еще утром был в курсе, что в обед на кухне тех же листьев нори уже не будет.
Enterprise Resource Planning, планирование ресурсов предприятия
ERP (англ. Enterprise Resource Planning, планирование ресурсов предприятия) — организационная стратегия интеграции производства и операций, управления трудовыми ресурсами, финансового менеджмента и управления активами, ориентированная на непрерывную балансировку и оптимизацию ресурсов предприятия посредством специализированного интегрированного пакета прикладного программного обеспечения, обеспечивающего общую модель данных и процессов для всех сфер деятельности. ERP-система — конкретный программный пакет, реализующий стратегию ERP. (с) Википедия
Термин ERP придумал Ли Уайли в 1990 году
Понятие ERP ввёл аналитик Gartner Ли Уайли (англ. Lee Wylie) в 1990 году в исследовании о развитии MRP II. Уайли спрогнозировал появление тиражируемых многопользовательских систем, обеспечивающих сбалансированное управление всеми ресурсами организации, не только относящихся к основной деятельности производственного предприятия, но и объединяющих посредством общей модели данных данные о производстве, закупках, сбыте, финансах, кадрах. (с) Википедия
Вы начали писать все верно, по потом пошла какая-то вода: «как правило, но есть много исключений», «может импортировать, а может и не делать этого», «имеется тенденция»… Прямо как Гидромецентр со своими прогнозами: может дождь, может снег, может будет, может нет :)
По факту: главной идеей и целью концепции и программ ERP является рачительное управление производственными ресурсами. Именно из-за несоответствия описанного функционала к примененному термину ERP, я прицепился к автору. Про планировании закупок не было ни слова, как я уже упомянул выше. Так же ни слова не сказано даже о самом базовом — планировании самого производства. Где-то в комментариях автор упомянул, что там в его системе есть рецепты, но он про такой «очевидный» функционал просто не стал писать. Этого мало! Те же рецепты можно на листиках от руки написать и на стенках повесить. А должен быть как минимум анализ потребностей кухни на основе уже собранных заказов (плюс прогнозируемые заказы на базе собранной в прошедшие периоды статистики), что бы завхоз еще утром был в курсе, что в обед на кухне тех же листьев нори уже не будет.
Подскажите, пожалуйста, что не так с целью оптимизации и контроля за производством: в каждый конкретный момент система говорит что делать конкретному сотруднику, перераспределяет нагрузки между кухнями, контролирует выполнение и так далее. Почему это не ERP? Не понимаю.
В этом бизнесе опоздание и пересорт — самые частые косяки. Не заметны убытки от того, что испортилась какая-то залежавшаяся рыба на фоне 2-х отказов за день из-за косяка повара, который по запарке перепутал ингредиенты. Или косяка, что нет доставщика на точке в важный момент, так как все 4-5 стоят в пробках из-за не оптимально составленных рейсов.
В этом бизнесе опоздание и пересорт — самые частые косяки. Не заметны убытки от того, что испортилась какая-то залежавшаяся рыба на фоне 2-х отказов за день из-за косяка повара, который по запарке перепутал ингредиенты. Или косяка, что нет доставщика на точке в важный момент, так как все 4-5 стоят в пробках из-за не оптимально составленных рейсов.
Нельзя просто взять сказать «я сделал ERP-систему» и далее рассказывать о том, как парсишь PDF-документ и с телефона передаешь GPS-трек. Нельзя, потому что самое быстрое внедрение уже готовой ERP-системы про которое я слышал заняло три месяца (настройки, обучение, перенос данных). Внедрения с доработками идут по году. А написание систем для управления ресурсами предприятия «с нуля» занимает годы.
Что еще не так в статье? Не сказано, чем именно не устраивала система FARFOR, какие блоки автоматизации процессов были доработаны и какие вообще написаны заново, как именно была выполнена связка с основной системой? Я так и не понял — у вас «прокси» на корпоративный софт с вашим дополнительным функционалом или отдельная самостоятельная полноценная система, которая никак не зависит от легаси и имеет с ней двухстороннюю синхронизацию как отключаемую опцию? В целом, ну никак не показана ценность созданной системы. У меня сложилось впечатление, что вы просто какой-то плагин сделали, который работает исключительно поверх чужой программы.
Что еще не так в статье? Не сказано, чем именно не устраивала система FARFOR, какие блоки автоматизации процессов были доработаны и какие вообще написаны заново, как именно была выполнена связка с основной системой? Я так и не понял — у вас «прокси» на корпоративный софт с вашим дополнительным функционалом или отдельная самостоятельная полноценная система, которая никак не зависит от легаси и имеет с ней двухстороннюю синхронизацию как отключаемую опцию? В целом, ну никак не показана ценность созданной системы. У меня сложилось впечатление, что вы просто какой-то плагин сделали, который работает исключительно поверх чужой программы.
Попробую зайти из далека и объяснить принципиальные вещи.
Существует две производственные модели:
1. Выталкивающий типа, когда делается анализ рынка и строится производственный план. И далее весь произведенный товар выкидывается на рынок и его толкают.
2. Вытягивающего типа, когда делается заказ, и уже производственная система производит товар согласно заказу.
Как не сложно догадаться, ваша система вытягивающего типа. ERP система — это система поддерживающая первый, выталкивающий тип производства.
Поэтому ваша система просто по определению не может быть ERP. Там другие алгоритмы и модели управления производством. Поэтому, ERP звучит очень модно и люди часто используют это слово для продвижения своей системы. Тут ничего плохого нет. Только у вас не ERP. Вам нужно позиционироваться как системы вытягивающего типа, там своя терминология, и тоже не менее популярна. Например, бережливое производство LEAN Production.
ru.wikipedia.org/wiki/%D0%91%D0%B5%D1%80%D0%B5%D0%B6%D0%BB%D0%B8%D0%B2%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B8%D0%B7%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE
Существует две производственные модели:
1. Выталкивающий типа, когда делается анализ рынка и строится производственный план. И далее весь произведенный товар выкидывается на рынок и его толкают.
2. Вытягивающего типа, когда делается заказ, и уже производственная система производит товар согласно заказу.
Как не сложно догадаться, ваша система вытягивающего типа. ERP система — это система поддерживающая первый, выталкивающий тип производства.
Поэтому ваша система просто по определению не может быть ERP. Там другие алгоритмы и модели управления производством. Поэтому, ERP звучит очень модно и люди часто используют это слово для продвижения своей системы. Тут ничего плохого нет. Только у вас не ERP. Вам нужно позиционироваться как системы вытягивающего типа, там своя терминология, и тоже не менее популярна. Например, бережливое производство LEAN Production.
ru.wikipedia.org/wiki/%D0%91%D0%B5%D1%80%D0%B5%D0%B6%D0%BB%D0%B8%D0%B2%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B8%D0%B7%D0%B2%D0%BE%D0%B4%D1%81%D1%82%D0%B2%D0%BE
«ERP система — это система поддерживающая первый, выталкивающий тип производства.»
А пруфы будут?
А пруфы будут?
MRP (англ. Material Requirements Planning — планирование потребности в материалах) — система планирования потребностей в материалах, одна из наиболее популярных в мире логистических концепций, на основе которой разработано и функционирует большое число микрологистических систем. На концепции MRP базируется построение логистических систем «толкающего типа».
Это википедия MRP.
Это логично, так как ERP — это система планирования ресурсов предприятия, необходимых для выпуска заданного объема продукции в условленное время.
Это википедия MRP.
Это логично, так как ERP — это система планирования ресурсов предприятия, необходимых для выпуска заданного объема продукции в условленное время.
MRP не обязательно подразумевает «толкающий тип» — почитайте более подробно, какие именно алгоритмы там применяются. Википедия не является истиной в последней инстанции.
Но можно сделать проще — поищите, сколько ERP систем поддерживают «производство на заказ» — удивитесь. :))) А это классический пример «вытягивания».
Но можно сделать проще — поищите, сколько ERP систем поддерживают «производство на заказ» — удивитесь. :))) А это классический пример «вытягивания».
«Это мексиканский тушкан. — Быть этого не может. Вас обманули. Вам дали гораздо лучший мех.»
Вы можете называть все что угодно словом ERP и забивать гвозди тапочкам.
MRP — это определенный стандарт управления ресурсами предприятия
en.wikipedia.org/wiki/Material_requirements_planning
Там четко описано что есть вход и что есть выход.
Данные [ править ]
Данные, которые необходимо учитывать, включают:
Создается конечный элемент (или элементы). Это иногда называют независимым спросом или уровнем «0» в спецификации ( спецификация материалов ).
Сколько требуется за раз.
Когда количества требуются для удовлетворения спроса.
Срок хранения хранящихся материалов.
Записи состояния инвентаря. Записи чистых материалов, доступных для использования уже на складе (под рукой) и материалов по заказу от поставщиков.
Законопроекты. Подробная информация о материалах, компонентах и подузлах, необходимых для изготовления каждого продукта.
Данные планирования. Это включает в себя все ограничения и направления для создания таких элементов, как: стандарты маршрутизации, труда и машины, стандарты качества и тестирования, команды pull / work и push, методы определения размера партии (т. Е. Фиксированный размер лота, лот-лот, экономический порядок количества), количества отходов и других материалов.
Существует два выхода и множество сообщений / отчетов:
Выход 1 — это «Рекомендуемый график производства». Это излагает подробный график требуемых минимальных дат начала и завершения с указанием количества для каждого шага Маршрутизации и Билля материала, необходимого для удовлетворения потребности в главном графике производства (MPS).
Результат 2 — «Рекомендуемый график закупок». Это определяет как даты, в которые приобретаемые товары должны быть получены в объект, так и даты, когда должны выполняться заказы на поставку или выпуск бланкета, чтобы соответствовать графику производства.
Вы можете называть все что угодно словом ERP и забивать гвозди тапочкам.
MRP — это определенный стандарт управления ресурсами предприятия
en.wikipedia.org/wiki/Material_requirements_planning
Там четко описано что есть вход и что есть выход.
Данные [ править ]
Данные, которые необходимо учитывать, включают:
Создается конечный элемент (или элементы). Это иногда называют независимым спросом или уровнем «0» в спецификации ( спецификация материалов ).
Сколько требуется за раз.
Когда количества требуются для удовлетворения спроса.
Срок хранения хранящихся материалов.
Записи состояния инвентаря. Записи чистых материалов, доступных для использования уже на складе (под рукой) и материалов по заказу от поставщиков.
Законопроекты. Подробная информация о материалах, компонентах и подузлах, необходимых для изготовления каждого продукта.
Данные планирования. Это включает в себя все ограничения и направления для создания таких элементов, как: стандарты маршрутизации, труда и машины, стандарты качества и тестирования, команды pull / work и push, методы определения размера партии (т. Е. Фиксированный размер лота, лот-лот, экономический порядок количества), количества отходов и других материалов.
Существует два выхода и множество сообщений / отчетов:
Выход 1 — это «Рекомендуемый график производства». Это излагает подробный график требуемых минимальных дат начала и завершения с указанием количества для каждого шага Маршрутизации и Билля материала, необходимого для удовлетворения потребности в главном графике производства (MPS).
Результат 2 — «Рекомендуемый график закупок». Это определяет как даты, в которые приобретаемые товары должны быть получены в объект, так и даты, когда должны выполняться заказы на поставку или выпуск бланкета, чтобы соответствовать графику производства.
Если решили углубиться в детали…
Сам по себе алгоритм MRP ничего не «решает» о количестве готовой продукции, которое необходимо получить на выходе. Основной план / график производства (спрос) — это входящая информация для алгоритма MRP.
Создаете график производства на основе неких планов — получаете «выталкивающую» схему (производственники говорят продажникам — вот, мы это произвели — продавайте).
Создаете график производства на основе фактических заказов от покупателей — и, ни одного байта не меняя в алгоритме MRP, — получаете «вытягивающую» схему (продажники говорят производственникам — вот, мы это продали — производите).
MRP ортогонален к противостоянию «выталкивание» / «вытягивание». Он вообще не про это.
Сам по себе алгоритм MRP ничего не «решает» о количестве готовой продукции, которое необходимо получить на выходе. Основной план / график производства (спрос) — это входящая информация для алгоритма MRP.
Создаете график производства на основе неких планов — получаете «выталкивающую» схему (производственники говорят продажникам — вот, мы это произвели — продавайте).
Создаете график производства на основе фактических заказов от покупателей — и, ни одного байта не меняя в алгоритме MRP, — получаете «вытягивающую» схему (продажники говорят производственникам — вот, мы это продали — производите).
MRP ортогонален к противостоянию «выталкивание» / «вытягивание». Он вообще не про это.
Такой способ вытягивания будет неэффективным при мелком производстве, это все работает при крупной партии заказа. Когда заказ может выступать планом. Тогда, соглашусь, можно не менять модель управления. И алгоритмы не изменятся. Это предельный случай. В случае с индивидуальным заказом блюда, такой подход не оптимален. Его можно использовать, но клиенты будут не довольны качеством и скоростью обслуживания.
Мы ведь про MRP, не про MRP II говорим?
Ну приведите пример более эффективного алгоритма для мелкого производства. :)
Ну приведите пример более эффективного алгоритма для мелкого производства. :)
Давайте рассмотрим схему изготовления блюд.
Есть договор с поставщиком продуктов, который находится не далеко. Поступает заказ на изготовление блюда, система анализирует небольшие запасы на кухне, если все есть, то заказ уходит на кухню. Изготавливается блюдо, далее передается в отдел доставки. Начальником транспортного цеха доставляется клиенту.
Если продукта нет или стало меньше критического значения, то автоматически формируется заявка на доставку необходимых продуктов у поставщика. Поставщик поставляет продукт и уже из него делается блюдо.
Получается схема, что клиент вытягивает блюдо, производитель блюда вытягивает ингредиенты. Тут нужно искать оптимум транзакционных издержек между хранением и заказом ингредиентов. Конечно без запаса продуктов не обойтись, но их можно минимизировать.
Идет непрерывный процесс вытягивания блюд клиентами. И можно гарантировать качество этих блюд. В общем, достаточно почесать репу и оптимизировать издержки по поставки продуктов поставщиком, как схема становится эффективней, чем MRP.
Есть договор с поставщиком продуктов, который находится не далеко. Поступает заказ на изготовление блюда, система анализирует небольшие запасы на кухне, если все есть, то заказ уходит на кухню. Изготавливается блюдо, далее передается в отдел доставки. Начальником транспортного цеха доставляется клиенту.
Если продукта нет или стало меньше критического значения, то автоматически формируется заявка на доставку необходимых продуктов у поставщика. Поставщик поставляет продукт и уже из него делается блюдо.
Получается схема, что клиент вытягивает блюдо, производитель блюда вытягивает ингредиенты. Тут нужно искать оптимум транзакционных издержек между хранением и заказом ингредиентов. Конечно без запаса продуктов не обойтись, но их можно минимизировать.
Идет непрерывный процесс вытягивания блюд клиентами. И можно гарантировать качество этих блюд. В общем, достаточно почесать репу и оптимизировать издержки по поставки продуктов поставщиком, как схема становится эффективней, чем MRP.
Вообще то, вы только что описали классический алгоритм MRP в связке с классическим алгоритмом пополнения запасов по минимаксу (именно так очень часто и работают ERP системы для недорогих видов запасов). :)))
А обещали описать какой-то другой алгоритм, более эффективный… Как после этого верить людям? :)))
Почитайте по ERP системам что-то более серьезное, чем википедия. Меньше будет велосипедов и выше качество решений.
А обещали описать какой-то другой алгоритм, более эффективный… Как после этого верить людям? :)))
Почитайте по ERP системам что-то более серьезное, чем википедия. Меньше будет велосипедов и выше качество решений.
Если человек в чем-то убежден, то флаг ему в руки. Если лучший молоток — это кирпич, тоже можно им забивать гвозди.
Вообще-то, я ссылался на Колумбийский университет. Там тоже для вас нет авторитета. Профессура у нас не в почете. Только рекламные проспекты в гугл, авторитет.
Замете вы за всю переписку не сделали не одной ссылки, но ссылаетесь на нечто серьёзное.
Ссылку, плиз, на нечто серьезное, что аргументирует ваши утверждения.
Вообще-то, я ссылался на Колумбийский университет. Там тоже для вас нет авторитета. Профессура у нас не в почете. Только рекламные проспекты в гугл, авторитет.
Замете вы за всю переписку не сделали не одной ссылки, но ссылаетесь на нечто серьёзное.
Ссылку, плиз, на нечто серьезное, что аргументирует ваши утверждения.
«Если человек в чем-то убежден, то флаг ему в руки.» :)))
Почитайте, например, ту лекцию Колумбийского университета, которую ВЫ и привели www.columbia.edu/~gmg2/4000/pdf/lect_06.pdf. :)))
И подставьте ваши данные — простой одноуровневый BOM (рецепт) и произвести надо «сейчас».
«MRP will determine from the master production schedule and the product structure records the
gross component requirements; the gross component requirements will be reduced by the available
inventory as indicated in the inventory status records.»
«Поступает заказ на изготовление блюда, система анализирует небольшие запасы на кухне, если все есть, то заказ уходит на кухню.
…
Если продукта нет или стало меньше критического значения, то автоматически формируется заявка на доставку необходимых продуктов у поставщика.»
Впрочем, если вам нравится изобретать велосипеды — дело ваше.
Почитайте, например, ту лекцию Колумбийского университета, которую ВЫ и привели www.columbia.edu/~gmg2/4000/pdf/lect_06.pdf. :)))
И подставьте ваши данные — простой одноуровневый BOM (рецепт) и произвести надо «сейчас».
«MRP will determine from the master production schedule and the product structure records the
gross component requirements; the gross component requirements will be reduced by the available
inventory as indicated in the inventory status records.»
«Поступает заказ на изготовление блюда, система анализирует небольшие запасы на кухне, если все есть, то заказ уходит на кухню.
…
Если продукта нет или стало меньше критического значения, то автоматически формируется заявка на доставку необходимых продуктов у поставщика.»
Впрочем, если вам нравится изобретать велосипеды — дело ваше.
В моем примере, оптимизация достигается не за счет управления ресурсами, а за счет оптимизации отношений с поставщиком продукта. Там цели оптимизации другие. Это ключевое отличие. Вы пытаетесь найти в вытягивающий модели вырожденный случай выталкивающей системы. И свести ее к управлению ресурсами. Вытягивающая система делает акцент на управление процессами. Это принципиально другой взгляд на производство. MRP перед собой такой задачи не ставит.
:)))
Да-да, я понял — вы придумали не велосипед, а ногоезд.
И он сильно круче велосипеда, так как принципиально другой.
Да-да, я понял — вы придумали не велосипед, а ногоезд.
И он сильно круче велосипеда, так как принципиально другой.
Американцы также думали, до 80-х годов, пока их пинками не вышибли с рынка автопрома японцы. Сейчас они активно пересматривают свои производственные модели и отношение к ним.
Видите ли, если бы Деминг не потрудился в свое время глубоко изучить работы Шухардта, вряд ли он смог бы придумать то, что японцы называют циклом Деминга, а сам Деминг называл циклом Шухарта (PDSA цикл). :)))
Как показывает опыт, люди, не удосужившиеся изучить изобретенное предшественниками, в 99% изобретают не просто велосипед, а плохой велосипед.
Впрочем — дерзайте. Есть желание изобретать велосипеды и называть их новыми словами — кто я такой, чтобы мешать?
Как показывает опыт, люди, не удосужившиеся изучить изобретенное предшественниками, в 99% изобретают не просто велосипед, а плохой велосипед.
Впрочем — дерзайте. Есть желание изобретать велосипеды и называть их новыми словами — кто я такой, чтобы мешать?
И как PDCA цикл Шухарта-Деминга связан с MRP моделью и управлением ресурсов? Деминг как раз делает свой акцент на постоянном и непрерывном улучшении качества производственного процесса. Тоже что и я, непрерывное улучшение качества отношений между производителем блюд и поставщиком продуктов. Чистая опора на классиков жанра. А вот попытка использовать коньки по льду на асфальте, просто потому что вы на них умеете кататься, это точно хуже плохого велосипеда.
PDCA цикл Шухарта-Деминга никак не связан с MRP алгоритмом.
А вот то, что Деминг, прежде чем придумывать что-то свое, внимательно изучил опыт предшественников — очень даже связано с вашими «открытиями». Ведь вы даже не удосужились разобраться — что такое MRP. Вы ведь, судя по всему, даже ту лекцию Колумбийского университета не прочитали, ссылку на которую привели. :)
Когда программист начинает рассказывать байки про «улучшение качества отношений», как PR менеджер — сразу вспоминается анекдот про морскую свинку, которая ни к морю, ни к свиньям отношения не имеет.
С чего обсуждение начиналось?
«ERP система — это система поддерживающая первый, выталкивающий тип производства.»
В качестве доказательства привели сомнительную статью на википедии и ссылку на лекцию Колумбийского универа.
В лекции черным по белому написано:
«The three major inputs of an MRP system are the master production schedule, the product
structure records, and the inventory status records.»
Вместо того, чтобы или доказать, каким образом MRP является «выталкивающим» при том, что план производства является для него входящими данными, или признать свою ошибку, вы начинаете рассказывать байки про улучшение отношений.
А вот то, что Деминг, прежде чем придумывать что-то свое, внимательно изучил опыт предшественников — очень даже связано с вашими «открытиями». Ведь вы даже не удосужились разобраться — что такое MRP. Вы ведь, судя по всему, даже ту лекцию Колумбийского университета не прочитали, ссылку на которую привели. :)
Когда программист начинает рассказывать байки про «улучшение качества отношений», как PR менеджер — сразу вспоминается анекдот про морскую свинку, которая ни к морю, ни к свиньям отношения не имеет.
С чего обсуждение начиналось?
«ERP система — это система поддерживающая первый, выталкивающий тип производства.»
В качестве доказательства привели сомнительную статью на википедии и ссылку на лекцию Колумбийского универа.
В лекции черным по белому написано:
«The three major inputs of an MRP system are the master production schedule, the product
structure records, and the inventory status records.»
Вместо того, чтобы или доказать, каким образом MRP является «выталкивающим» при том, что план производства является для него входящими данными, или признать свою ошибку, вы начинаете рассказывать байки про улучшение отношений.
www.columbia.edu/~gmg2/4000/pdf/lect_06.pdf
Ссылка на пример использования алгоритма. Это уже Колумбийский университет.
Ссылка на пример использования алгоритма. Это уже Колумбийский университет.
Так может стоило более подробно разобраться и донастроить?
Что донастраивать, если просто НЕТ этого функционала? Ни из коробки, ни вообще.
В целом мне кажется статья получилась скомканная. Я не понял прелестей ни Delphi, ни RAD studio, и не понял о чем система, почему же она «мощная».
Что именно не понятно?
Ответьте для начала на мои вопросы в коментарии
Прочитайте для начала текст статьи. Там всё описано. Зачем задавать вопрос, если статью не читал?
НЛО прилетело и опубликовало эту надпись здесь
Что умеет система, чего не умеют другие? Система заточена под конкретный бизнес. Аналогов в данной области ей нет. Просто нет, так как там конкуренты типа ArchiDelivery и Farfor ERP. То есть ни о чём. Я за пару месяцев вывел функционал на более высокий уровень, чем они пиля годами и 10-ю программистами. Но область достаточно специфичная, крупные игроки её или всерьёз не воспринимают, или вовсе не знают о ней. Почему — свечку не держал.
Про остальное -достоинства RAD Studio — в статье постарался подробно изложить. А о донастройке систетемы — сам не понял о чём автор поста сказал. Причём тут windows/linux/mac вообще.
Про остальное -достоинства RAD Studio — в статье постарался подробно изложить. А о донастройке систетемы — сам не понял о чём автор поста сказал. Причём тут windows/linux/mac вообще.
То есть целые команды и продукты ни о чем? Только наш «одинокий рейнджер/ниндзя» знает и могёт лучше, чем все эти… Да тут мания величия на лицо. Хотя лучше всего вашу статью вашу статб описывает комментарий ниже https://m.habrahabr.ru/post/345274/comments/#comment_10582048
Когда целая команда из 8 человек за месяц не может найти куда пропадают заказы с планшета — говорит о многом.
Что же до того комментария — вот как я могу постороннему человеку продемонстрировать работу своего ПО? Дать логин/пароль? Может сразу админский?
P.S. Я предпочитаю троллей не кормить.
Что же до того комментария — вот как я могу постороннему человеку продемонстрировать работу своего ПО? Дать логин/пароль? Может сразу админский?
P.S. Я предпочитаю троллей не кормить.
> Когда целая команда из 8 человек за месяц не может найти куда пропадают заказы с планшета — говорит о многом.
Говорит что руководство не умеет адекватно взаимодействовать с ИТшниками (наприме: некорректно ставят задачи, не адекватно платят, не требуют результатов/не контролируют). Тут бы новому исполнителю ИТшнику насторожиться бы. А нет — полезем головой в петлю. Хоть предоплату то взяли?
Приятно конечно мнить себя в восемь раз более эффективным чем коллеги. Однако это было бы так если бы этот одиночка-«гений» сумел бы внедрить систему.
А невнедренная система ни о чем не говорит.
Может ее при внедрении переделывать да доделывать на 90% еще.
Говорит что руководство не умеет адекватно взаимодействовать с ИТшниками (наприме: некорректно ставят задачи, не адекватно платят, не требуют результатов/не контролируют). Тут бы новому исполнителю ИТшнику насторожиться бы. А нет — полезем головой в петлю. Хоть предоплату то взяли?
Приятно конечно мнить себя в восемь раз более эффективным чем коллеги. Однако это было бы так если бы этот одиночка-«гений» сумел бы внедрить систему.
А невнедренная система ни о чем не говорит.
Может ее при внедрении переделывать да доделывать на 90% еще.
Руководство поставило им простую задачу: на кухню и упаковку надо поставить планшеты, курьерам телефоны. Было это где-то в сентябре (могу чуть путать). И это не просто IT отдел, а целая контора (в гугле быстро ищется). Они рулят серверами, допиливают функционал. Нюансов их внутренней кухни я не знаю, но в середине декабря их решение по планшетам было почти готово. Последний месяц они искали «куда деваются заказы с планшета». Это цитата.
Да. Это так. Внедрение началось, достаточно успешно, и тут заказчик «включил заднюю». Поэтому я и решил посоветоваться с хар-сообществом, но вместо позитива меня заминусовали. Ну что же. Бывает и такое.
А невнедренная система ни о чем не говорит.
Да. Это так. Внедрение началось, достаточно успешно, и тут заказчик «включил заднюю». Поэтому я и решил посоветоваться с хар-сообществом, но вместо позитива меня заминусовали. Ну что же. Бывает и такое.
. Поэтому я и решил посоветоваться с хар-сообществом, но вместо позитива меня заминусовали. Ну что же. Бывает и такое
То есть вариант что здесь люди знающие и если они говорят что вы сделали ни то — вы исключаете и им не верите?
Поэтому я и решил посоветоваться с хар-сообществом, но вместо позитива меня заминусовали.
Я хоть и не плюсовал, но и не минусовал. Как-то нейтрален к вашей истории. Но вам не нужно сейчас включать обиженного и жаловаться на непонимание сообществом. Если хотели посоветоваться, то нужно было открыто просить совета в статье, а не пиарить RAD Studio и не пытаться искать потенциальных заказчиков на оказавшуюся ненужной программу.
Мне не понятна ваша реакция.
Лейтмотив вашей статьи и комментариев — это противопоставление вас одного целому пласту науки о проектировании ПО и профсообществу. Статья более, чем туманна:
Вы восхваляете свои решения, но при этом выдаете либо "эскизы" кода, либо вовсе умалчиваете о реализации, говоря обобщенно.
Вы описываете предпосылки создания субъективным желанием без даже малейших попыток анализа существующих решений.
Вы описываете систему немногочисленными возможностями, тут же называете ее "мощной", но абсолютно умалчиваете об инфраструктуре решения, не называете ни сроков реализации, ни заявленных требований, ни критериев качества по которым можно оценить результаты.
Вы пытаетесь акцентировать внимание на ЯП и инструменты разработки, которые к вашей т.н. ERP имеют посредственное отношение.
вот как я могу постороннему человеку продемонстрировать работу своего ПО? Дать логин/пароль? Может сразу админский?
А демонстрация системы ограничивается только передачей админского пароля?
Вместо того, чтобы хамить и обзывать троллями, вы бы могли просто нас просвятить и выпустить две отдельные статьи одна — презентация системы, другая — о том, как здорово работать в RAD studio. Блесните знаниями и опытом более детально.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
А у меня вопрос один, вы студию купили или с торрентов скачали, а друг вас кинул с оплатой?
Возможны разные пути «бесплатно» получить лицензию: named через работодателя или «одолжить» concurrent лицензию у друга. Простите, но я считаю, что нет смысла здесь это обсуждать и, тем более, намекать о пиратстве практически ничего о авторе не зная.
Правила лицензирования Rad Studio
Правила лицензирования Rad Studio
опАздание?
"Мощная ERP", один человек делал… Что-то совсем не сходится. Я бы ещё понял, если бы лёгкая и персонализированная под конкретного заказчика без лишнего функционала...
Эх, сразу вспоминаю университет и свою «мощную ERP», которую писал для диплома. Спасибо за статью, всплакнул.
Нет ТЗ и договора — результат ХЗ и без денег.
Многим, я думаю, будет интересно узнать какого вообще разрабатывать кросс-платформенные приложения на RAD Studio
Либо после слова "какого" пропущено слово на букву "х", либо… впрочем, меня и этот вариант устраивает.
Каждый должен написать свой велосипед) Это, конечно, не ERP, но для небольшой компании может быть востребовано — только описание нужно сделать толковое. Про то, как разошлись с заказчиком, можно не говорить, достаточно сказать, что система в бета-релизе. Желаю удачи.
PS: Грамматические и орфографические ошибки нужно вычитывать перед публикацией.
Когда читал статью, был в шоке.
Сам в основном занимаюсь разработкой ERP, CRM.
Очень рад за клиента, что он отказался и надеюсь не заплатил.
Автор, когда клиент к тебе обращается — он ждет что-то хорошее.
А ты с момента выбора технологии и реализации начал клиенту свинью подкладывать.
ERP такая штука, которая всегда подвержена доработкам и изменениям, притом доработкам, порой очень нелогичным (которые не укладываются в логику).
Такие системы должны быть:
1. Очень гибкие — чтоб можно было менять и дорабатывать все что угодно, особо при этом не ломая другие модули
2. Написаны на популярных и простых технологиях — если вдруг за такой код, как вы делали, вас в лес увезут, чтоб другой программист мог дальше работать. Ваш код легче выкинуть, чем копаться в ваших изобретениях.
И да, согласен с этим комментом habrahabr.ru/post/345274/#comment_10581006
И вобще, я засмеялся когда прочел это
Вы там зазвездились? Вы сделали и пусть работают как хотят с вашими костылями? )))
И что за дер… код вы написали, при котором все переписывать надо?) Да и в целом сразу не догадались, чтоб будут такие проблемы?)
Выбрали ЯП для задачи, которую намного лучше решать другими ЯП -> Сами в статье написали что нихрена оно не удобно и вы написали свой редактор форм (Карррл, уже тут надо было СТОП) -> на нем все закодили. А потом вдруг оно не гибким оказалось? Пришлось не код под функционал, а функционал под код подстраивать?? КАААРЛ!!!
А как вы сделали рассылку кэша по клиентам?
Я так понял вы при каждом обновлении рассылали кэш по всем клиентам? в Оперативку всю базу по сути??? Вы там совсем упали с высоты, слово на букву е.. чтоли???
Пошел пить валидол…
Сам в основном занимаюсь разработкой ERP, CRM.
Очень рад за клиента, что он отказался и надеюсь не заплатил.
Автор, когда клиент к тебе обращается — он ждет что-то хорошее.
А ты с момента выбора технологии и реализации начал клиенту свинью подкладывать.
ERP такая штука, которая всегда подвержена доработкам и изменениям, притом доработкам, порой очень нелогичным (которые не укладываются в логику).
Такие системы должны быть:
1. Очень гибкие — чтоб можно было менять и дорабатывать все что угодно, особо при этом не ломая другие модули
2. Написаны на популярных и простых технологиях — если вдруг за такой код, как вы делали, вас в лес увезут, чтоб другой программист мог дальше работать. Ваш код легче выкинуть, чем копаться в ваших изобретениях.
И да, согласен с этим комментом habrahabr.ru/post/345274/#comment_10581006
И вобще, я засмеялся когда прочел это
потому что иначе это работать не будет (к слову, это требования полного переписывания всего на другом ЯП, просто «чтобы было»)
Вы там зазвездились? Вы сделали и пусть работают как хотят с вашими костылями? )))
И что за дер… код вы написали, при котором все переписывать надо?) Да и в целом сразу не догадались, чтоб будут такие проблемы?)
Выбрали ЯП для задачи, которую намного лучше решать другими ЯП -> Сами в статье написали что нихрена оно не удобно и вы написали свой редактор форм (Карррл, уже тут надо было СТОП) -> на нем все закодили. А потом вдруг оно не гибким оказалось? Пришлось не код под функционал, а функционал под код подстраивать?? КАААРЛ!!!
А как вы сделали рассылку кэша по клиентам?
Я так понял вы при каждом обновлении рассылали кэш по всем клиентам? в Оперативку всю базу по сути??? Вы там совсем упали с высоты, слово на букву е.. чтоли???
Пошел пить валидол…
Судя по наличию слова «подписчики», клиенты подписываются на изменения интересующих их сущностей.
То есть для руководителя и помощника руководителя, для полноценной работы по сути все должно грузиться?)
Допустим база клиентов в 150К с адресами, историей заказов и т.п.
Оно как на сервере… захадркожена пагинация которая на клиенте и отдаются клиенты в соответствии с текущей страницей или все сразу?
Если отдается в соответствии с текущей страницей, всякие фильтры, сортировки — это уже отдельно на сервере вычисляется из кэша и отдается или как?
Если отдается вся база в 150К пользователей с зависимостями, как оно там на клиенте сортируется, да и в целом хранится)
Допустим база клиентов в 150К с адресами, историей заказов и т.п.
Оно как на сервере… захадркожена пагинация которая на клиенте и отдаются клиенты в соответствии с текущей страницей или все сразу?
Если отдается в соответствии с текущей страницей, всякие фильтры, сортировки — это уже отдельно на сервере вычисляется из кэша и отдается или как?
Если отдается вся база в 150К пользователей с зависимостями, как оно там на клиенте сортируется, да и в целом хранится)
Клиент сам решает на что подписаться и сообщает серверу о своём решении. Обычно, да, текущая страница списка +- несколько для плавной прокрутки, если говорить об отображении списков. Детализация — по месту решается, если строка списка отличается от полного представления несколькими полями, то проще сразу отдать их, если разница в разы или на порядки, то сделать отдельный запрос.
У нас, когда столкнулись с сайтом на Ruby, люди сделали какашку, а нам предлагали взять после них на поддержку, родилась шутка, что сайты нужно было делать на Erlang, а дальше как в анекдоте:
Украинец и еврей отбились от каравана в пустыне, каждый естественно прихватил самое дорогое себе, украинец -мешок с салом, еврей — мешок с золото. Еврею кушать хочется, и говорит:
- Давай играть в рынок. Ты будешь продать сало, а я буду покупателем.
- Хорошо.
- Сколько у тебя стоит 100 грамм сала?
- Мешок золота.
- Не может быть, почему так дорого?
- Ну не знаю, у меня так, походи по рынку, может дешевле найдешь.
Сознательно или несознательно, но выбор технологий сделан так, чтобы никто ничего не правил...
НЛО прилетело и опубликовало эту надпись здесь
Склад, сборка и доставка — это совсем не ERP.
Ну и написать ERP в одно лицо если и можно, то на это придется потратить лет 5+ и при этом очень неплохо разбираться в экономике. И немного программировать :)
Но самое интересное начнется потом, когда созданную «ERP» кто-то купит :)
Начнутся ошибки, хотелки (которые зачастую противоречат одна другой), падение производительности под нагрузкой (хотя-бы человек 150-200 одновременно), а самое главное — поддержка под текущее законодательство.
И весь описанный выбор фреймворков, классов и прочего инструментария окажутся такими не важными и не интересными…
Ну и написать ERP в одно лицо если и можно, то на это придется потратить лет 5+ и при этом очень неплохо разбираться в экономике. И немного программировать :)
Но самое интересное начнется потом, когда созданную «ERP» кто-то купит :)
Начнутся ошибки, хотелки (которые зачастую противоречат одна другой), падение производительности под нагрузкой (хотя-бы человек 150-200 одновременно), а самое главное — поддержка под текущее законодательство.
И весь описанный выбор фреймворков, классов и прочего инструментария окажутся такими не важными и не интересными…
Да если ERP под одно предприятие, не большое, как у заказчика из статьи, то в принципе можно. Только при этом надо писать по частям, много общаться и встречаться с заказчиком по поводу бизнес процессов. Т.к. обычно у таких заказчиков требования слабо формализованы изначально.
Ну и будет это все писать не то что долго, а скорее постоянно дорабатываться, годами.
Бизнес всегда меняется, предприниматель всегда крутится и меняет что-то. Под это обычно и система меняется.
Но как оказалось, не все это понимают)))
Ну и будет это все писать не то что долго, а скорее постоянно дорабатываться, годами.
Бизнес всегда меняется, предприниматель всегда крутится и меняет что-то. Под это обычно и система меняется.
Но как оказалось, не все это понимают)))
Да если ERP под одно предприятие, не большое, как у заказчика из статьи, то в принципе можно
Только это будет не ERP :)
Ведь всякие SAP-ы и прочие 1C-ы, не говоря о Галактиках — они ведь удавятся от бессилия.
И да, никто не спорит, что можно написать заказную систему для конкретного заказчика. Но при этом надо понимать, что «писатель» попал в рабство на всю жизнь. Он будет неотъемлемой частью написанного. Даже когда ему опостылет это писать :)
Ну и стоит посмотреть на этого «заказчика», который, кажется, не понимал, на что он подписывается в описанном случае.
Да, часто это проблема. Но, есть заказчик — найдется и исполнитель :)
Когда это пишется на популярных технологиях и фрэймворках профессионалом, не все так страшно.
Я когда пишу код, всегда пишу с тем расчетом, что в любой момент разработчик может сменится. И чтоб другой, кто увидит мой код и возьмет его доработку, мог как можно легче разобраться и приступить.
Ну и когда растет система, если один разработчик, надо бить в колокола и объяснять заказчику, что нужна команда, документация и т.п. Иначе с разбитым корытом останется :)
Когда это пишется на популярных технологиях и фрэймворках профессионалом, не все так страшно.
Я когда пишу код, всегда пишу с тем расчетом, что в любой момент разработчик может сменится. И чтоб другой, кто увидит мой код и возьмет его доработку, мог как можно легче разобраться и приступить.
Ну и когда растет система, если один разработчик, надо бить в колокола и объяснять заказчику, что нужна команда, документация и т.п. Иначе с разбитым корытом останется :)
У меня нет понимания, как может один человек хорошо разбираться с таком объеме предметной области. А если понимания не будет — будет стандартная софтина, созданная из говна и палок. Не потому, что писатель кривой, а потому, что понимания предмета нет.
Т.е. код и его качество — это вторичный вопрос (увы) по сравнению с качество постановки задачи.
Т.е. код и его качество — это вторичный вопрос (увы) по сравнению с качество постановки задачи.
Эксперты со стороны заказчика должны, прежде всего. разбираться и передать разработчику необходимую ему для реализации часть своих знаний предметной области. Что передали, то и получат. Да, хорошо, если разработчик разбирается, и может заметить, что, например, не переданы некоторые детали и уточнить их, или заметить, что требования не включают решения стандартных для отрасли проблем, с которыми заказчик ещё не столкнулся, но в обозримом будущем с большой вероятностью столкнётся. Но это не обязательно для успешного внедрения. Тут как раз качество кода роляет — насколько код готов к оперативным изменениям, когда заказчик увидит, что он получил не то, что хотел, а то, что озвучил.
Эксперты со стороны заказчика должны, прежде всего. разбираться и передать разработчику необходимую ему для реализации часть своих знаний предметной области.
Это не то, чтобы заблуждение, но такое внедрение, скорее всего, будет обречено на провал. Причина очень простая — заказчик будет пытаться всех своих текущих тараканов затащить в новую систему. При этом далеко не факт, что текущие тараканы: а) законны, б) корректны и в) оптимальны с точки зрения бизнеса заказчика. Их тянут по одной причине — они привычны!
Постановщик со стороны исполнителя обязан разбираться в предмете и обладать квалификацией для поддержания корректного и аргументированного спора по предмету.
И качество кода, повторюсь, здесь вторично. Первичная — общая архитектура системы, структура базы данных. Именно это определяет возможность модернизировать систему.
Если, условно говоря, у вас свойство «пол» физ.лица — это булево, то любое качество кода не позволит этой системе быть успешно внедренной на территории некоторых стран :)
Зависит от постановки целей проекта в целом. Если автоматизировать имеющиеся бизнес-процессы, то это одно. Если оптимизировать их, в том числе путём автоматизации, но и не только, то это совсем другое. В обоих случаях у заказчика могут быть описания имеющихся, а могут и не быть. Ещё вариант может быть: вот есть (дорогая, тормозная, ещё какие-то минусы) система с такой-то функциональностью, в которой нам нужно только то-то и то-то, надо сделать систему аналогичную, но только с нужной функциональностью.
Архитектуру я неразрывно связываю с качеством кода. А вот структуру базы уже нет — это тактические решения, а не архитектурные. Если, конечно, архитектура не завязана на конкретное хранилище, типа решения всю бизнес-логику хранить в хранимых процедурах PostgreSQL.
Если автоматизировать имеющиеся бизнес-процессы, то это одно.
Если автоматизировать бардак — получится автоматизированный бардак :)
Ещё вариант может быть: ....
А есть такие же, только перламутровые? :)
Я в данном случае не пытаюсь убедить вас в чем-то. Я озвучиваю свой опыт из очень большой практики автоматизации предприятий (10+ лет).
Любая доработка системы является компромиссом между хотелкой заказчика, предметной компетентностью исполнителя и возможностями дорабатываемой системы.
Вы поймите, если я закажу вам систему «как 1с» только дешевле — я от вас если что-то и получу, то очень не скоро. Ну т.е. совсем не скоро. И сильно не факт, что дешевле, чем купить готовое у той же 1С. А если добавить еще несколько хотелок — то, возможно, и никогда не получу.
Ну и (ИМХО): для экономического софта качество базы данных — это ключевое, стратегическое качество софтины. Ибо если существующая структура БД не позволяет обеспечить некоторые хотелки, это тянет за собой столько подпрыгиваний и такой геморой, что хочется убиться.
Вы поймите, если я закажу вам систему «как 1с» только дешевле — я от вас если что-то и получу, то очень не скоро. Ну т.е. совсем не скоро.
Ну, например, относительно быстро вы можете получить от меня систему ведения кассы на торговой точке, если только это вам и нужно от 1С. Но, вообще, 1С не очень пример, поскольку относительно дешевая. SAP или Галактика лучше :)
Ну и (ИМХО): для экономического софта качество базы данных — это ключевое, стратегическое качество софтины.
Не согласен в целом. Всё зависит от архитектуры — если она сильно завязана на схему данных, то вы правы. Если она, как говорится, storage agnostic, то выбор конкретной системы хранения не повлияет на функциональность. Не знаю как сейчас обстоят дела в той же 1С, но помнится были времена, когда она предлагала несколько вариантов хранения данных на выбор.
получить от меня систему ведения кассы на торговой точке, если только это вам и нужно от 1С
Вот это я точно не посоветую делать на 1с. Особенно, если кэшлайн длинный, номенклатура 700+ тысяч и проходимость хорошая.
И да, у меня будет много вопросов по вашему предложению :)
Если она, как говорится, storage agnostic, то выбор конкретной системы хранения не повлияет на функциональность.
Если вы под этим термином понимаете независимость от конкретной СУБД, то я вообще о другом. Я говорю именно о структуре базы данных. Какие там таблицы, что в них лежит и как эти таблицы связаны. В какой СУБД это лежит — вопрос 145. И если структура базы «плохая» — на функциональность это влияет напрямую и драматически.
Говоря "таблицы", вы, скорее всего, уже подразумеваете реляционные СУБД или даже SQL. Да и в целом, скорее всего, имеете в виду не функциональность, а нефункциональные требования типа скорости работы и потребляемой памяти.
Говоря «таблицы», вы, скорее всего, уже подразумеваете реляционные СУБД или даже SQL.
Да, SQL СУБД.
Да и в целом, скорее всего, имеете в виду не функциональность, а нефункциональные требования типа скорости работы и потребляемой памяти.
Конечно нет. Имеется ввиду и то и то.
Как структура СУБД может повлять на функциональность? Ну, считая, что все нужные данные для какой-то функциональности в базе есть и известно где они есть.
Как структура СУБД может повлять на функциональность?
У меня не получается осмыслить эту фразу :(
Но все-таки не стоит уходить глубже, т.к. в этом случае мы скатываемся в предметную область. И без четкого описания обсуждаемого предмета хорошей дискуссии не получится, т.к. стороны будут вольны уточнять постановку в процессе дискуссии :)
ну условно, как повлияет на функциональность полностью нормализованная у нас база, полностью денормализованная или вообще EAV какая-то?
Скорее всего никак :) Ибо речь опять не о том.
…
Дальше будет притянутый за уши пример.
Пример: у вас есть таблица, которая хранит продажи со структурой: Товар, Количество, СуммаРубль, СуммаДоллар
Такая таблица доставит вам массу проблем, как только вы захотите продавать товар не только в долларах. Причем не только для задачи зафиксировать факт. А еще надо отчеты какие-то строить…
Такая таблица: Товар, Количество, Валюта1, Сумма1, Валюта2, Сумма2
Создаст значительно меньше проблем при двухвалютном учете, но трехвалютный уже не потянет. Специфика предметной области даст понимание, нужен нам трехвалютный учет или нет. Вот это и есть структура базы.
А теперь на секунду представляем себе, что самая первая структура данных успешно работала N лет. В базе накоплено X Гигабайт данных, с которыми работают M отчетов и всего остального. И теперь надо это все резко сделать многовалютным. И это надо сделать а) примерно вчера и б) база не будет остановлена больше, чем на пару минут/часов/дней (но всегда меньше, чем надо).
И вот тут сразу забывается качество кода, фреймворк, на котором все написано, и вся прочее. А начинаются размышления на тему: какрыбку съесть и кости сдать за деньги минимально дешево перелить данные из «старой» таблицы в «новую» и как потом сделать так, чтобы весь тот софт, который раньше работал с простыми циферками, стал быстро и правильно (!) работать с непростыми циферками.
На мой непросвященный взгляд — это и есть главная сложность. А на чем и как рисуются формочки и печатаются отчетики — это не самое интересное. SAP вон вполне себе работает на визуальных технологиях терминального века и ничего, живой :)
Ведь не зря вендоры экономического софта меряются не фреймворками и модными технологиями, а [десятками] тысяч работающих в одной базе пользователей и поддержкой актуального законодательства.
…
Дальше будет притянутый за уши пример.
Пример: у вас есть таблица, которая хранит продажи со структурой: Товар, Количество, СуммаРубль, СуммаДоллар
Такая таблица доставит вам массу проблем, как только вы захотите продавать товар не только в долларах. Причем не только для задачи зафиксировать факт. А еще надо отчеты какие-то строить…
Такая таблица: Товар, Количество, Валюта1, Сумма1, Валюта2, Сумма2
Создаст значительно меньше проблем при двухвалютном учете, но трехвалютный уже не потянет. Специфика предметной области даст понимание, нужен нам трехвалютный учет или нет. Вот это и есть структура базы.
А теперь на секунду представляем себе, что самая первая структура данных успешно работала N лет. В базе накоплено X Гигабайт данных, с которыми работают M отчетов и всего остального. И теперь надо это все резко сделать многовалютным. И это надо сделать а) примерно вчера и б) база не будет остановлена больше, чем на пару минут/часов/дней (но всегда меньше, чем надо).
И вот тут сразу забывается качество кода, фреймворк, на котором все написано, и вся прочее. А начинаются размышления на тему: как
На мой непросвященный взгляд — это и есть главная сложность. А на чем и как рисуются формочки и печатаются отчетики — это не самое интересное. SAP вон вполне себе работает на визуальных технологиях терминального века и ничего, живой :)
Ведь не зря вендоры экономического софта меряются не фреймворками и модными технологиями, а [десятками] тысяч работающих в одной базе пользователей и поддержкой актуального законодательства.
Тут не в структуре таблиц дело, прежде всего, а в том, что архитектурно заложен строго двухвалютный учёт. Основная проблема не в том, как столбцы называются, а в том что логика, код не заточены под мультивалютный. Изменение структуры данных задача относительно простая, даже вообще без даунтайма, при нормальном коде, в частности в случае когда все операции, которым известно про структуру данных, находятся в одном месте типа репозитория. По сравнению с задачей доработки бизнес-логики.
Изменение структуры данных задача относительно простая, даже вообще без даунтайма
Расскажите, пожалуйста, это Борису Нуралиеву. А то мы тут мучаемся с их наиболее распиаренным продуктом (якобы флагманским) 1С:ERP. Каждый раз приходится простой согласовывать, причем простой где-то в середине ночи.
Я говорю о системах, где у вас достаточно полный контроль над кодовой базой. Грубо, о "самописе", в котором вы можете, например, без особых проблем организовать запись в две таблицы (старая и новая) новых данных, пока где-то в фоне переливаются сотни гигабайт старых.
Расскажите, пожалуйста, это Борису Нуралиеву. А то мы тут мучаемся с их наиболее распиаренным продуктом (якобы флагманским) 1С:ERP. Каждый раз приходится простой согласовывать, причем простой где-то в середине ночи.
Ваш оппонент забыл упомянуть чем приходиться платить за "изменение без даунтайма" и пояснить почему все таки при всех их недостатках по гибкости от реляционных СУБД полностью не отказались до сих пор.
Изменение структуры данных задача относительно простая,
Для понимания вопроса — можете озвучить свой реальный опыт по изменению структуры таблиц в боевой БД размером гигов 100 и порядка 100 активных пользователей или ваш опыт чисто теоретический?
По сравнению с задачей доработки бизнес-логики.
При правильной структуре БД доработки бизнес-логики, можно считать, бесплатны. Хотя смотря что называть бизнес-логикой :)
Не согласен в целом. Всё зависит от архитектуры — если она сильно завязана на схему данных, то вы правы. Если она, как говорится, storage agnostic, то выбор конкретной системы хранения не повлияет на функциональность. Не знаю как сейчас обстоят дела в той же 1С, но помнится были времена, когда она предлагала несколько вариантов хранения данных на выбор.
Качество базы данных — это не СУБД, а качество логической структуры (ER диаграммы). Если структура хорошая, то её можно для начала хоть на SQLite реализовать, а потом переносить на другие субд, и все обойдется относительно небольшими переделками. А если структура базы плохая — такую ERP ничего не спасет.
к слову, это требования полного переписывания всего на другом ЯП, просто «чтобы было»
То есть у вас есть нестандартная среда разработки (редактор форм), свой скриптовый язык, движок для него написан на устаревшем языке, компилятор которого к тому же стоит немало, и вы считаете, что это недостаточные причины просить использовать другой язык? Где и за какие деньги ему искать программиста искать для доработки, если с вами связь потеряется или вы будете слишком заняты на другой работе? А потом еще ждать, пока программист в документации на все это разберется (у вас ведь она есть).
И вопросов по реализации здесь тоже хватает.
Почитал комменты автора, думаю эти вопросы написать не помешает.
Скрытый текст
необходимо интегрировать с существующей системой максимально скрытно
“работает быстрее, чем текущая система”
Ну так вы не весь функционал сделали, а только часть, естественно она будет быстрее работать.
типа NodeJS для сервера, и отдавать web-интерфейс клиентам – самый простой, но самый тормозной вариант (аналогичные решения требуют i3)
Почитайте что-ли как делаются API (серверные) и что такое WebSocket. А для вашего черно-белого интерфейса никакого i3 не надо.
но любое небольшое изменение в каком-то алгоритме требует пересборки и обновления всех программ
а всю логику убрать в скрипты
Отказались от скриптового серверного NodeJS, но в результате все равно сделали скрипты на сервере. К чему тогда слова про единую кодовую базу?
ShowMessage('Нельзя производить действия с завершенным заказом');
TransactionCanAccept;
То есть у вас клиент коннектится напрямую к базе? А пароль захардкожен или вы каждому свой выдаете? А если оператор SQL-клиент скачает?
не надо повторно пересобирать программы и обновлять всё везде. Достаточно клиенту перелогиниться.
Ну так в web, от которого вы отказались, все это есть из коробки. Достаточно страницу обновить.
во всех нынешних решениях – это латентность. Любое действие приводит к select из базы
Во всех решениях на Delphi? Возможно. О чем это говорит? Что она плохо подходит для таких приложений.
я сделал кэширование всех нужных данных в ОЗУ, и выборку оттуда через запросы. Сервер напрягается лишь транзакциями update/insert
Всё очень быстро, и без единого обращения на сервер
А если оператор захочет вчерашний заказ открыть? Вы всю таблицу с заказами на клиент вытаскиваете? Судя по контексту второй фразы, еще и с промежуточными таблицами. Вместо i3 требуем оперативную память.
тоже пришлось сделать интересные оптимизации
Ага, специально взяли себе проблему и героически ее решаем.
'Order|Orders->CustomerAddress|Customer_address->FiasHouse|Fias_Houses->ID'
Это все в виде ассоциативных массивов, без всякой типизации?
спасибо, что исходники компонент дельфи доступны и там можно легко поправить заголовок не заморачиваясь с raw socket
Даа, изменили системные компоненты? То есть у стороннего программиста, скачавшего установщик с сайта, оно в принципе не заработает?
НЛО прилетело и опубликовало эту надпись здесь
Многие накинулись на автора, мол, непопулярный язык, странное решение (xml для описания форм), и т.д., но вот вопрос: а было ли в первоначальной постановке задачи хоть что-то про желаемый заказчиком набор технологий?
И даже если был бы описан язык (к примеру, PHP+JS), то это никак бы не уберегло от непопулярных фреймворков, старых релизов (или наоборот, слишком новых, которые бы поддерживались 10% клиентских устройств), и вот таких вариантов с самописными (или не совсем) xml-template разметками.
И даже если был бы описан язык (к примеру, PHP+JS), то это никак бы не уберегло от непопулярных фреймворков, старых релизов (или наоборот, слишком новых, которые бы поддерживались 10% клиентских устройств), и вот таких вариантов с самописными (или не совсем) xml-template разметками.
Это уже вопрос профессионализма автора и клиента. Клиент решил не делать свой отдел для разработки, а взять одного удаленного человека.
Теперь он знает, что это путь в никуда.
Теперь он знает, что это путь в никуда.
Клиент без опыта (вроде очевидно), взял человека, предположительно, без опыта разработки больших систем напрямую конечному заказчику = результат немного предсказуем.
Дело не в формате работы, имхо. Дело в качестве начальной проработки требований к ИС (как функциональных, так и общих).
Т.е. с тезисом про профессионализм согласен, с тезисом про формат удаленщика-фрилансера — не согласен.
Дело не в формате работы, имхо. Дело в качестве начальной проработки требований к ИС (как функциональных, так и общих).
Т.е. с тезисом про профессионализм согласен, с тезисом про формат удаленщика-фрилансера — не согласен.
Я скорее про формат одного человека хотел сделать акцент.
Нельзя быть уверенным в одном человеке, лучше всегда иметь 2-х программистов, больше вероятность успеха)
Нельзя быть уверенным в одном человеке, лучше всегда иметь 2-х программистов, больше вероятность успеха)
И бюджет на двух программистов. Если это не вчерашние студенты или не демпингующие специалисты из Горно-Алтайска (любой другой Тьмутаракани по-вашему вкусу), то это недешевое удовольствие.
Когда я выступал заказчиком на биржах, и сроки горели, я обычно заказывал реализацию у двух разных независимых фрилансеров. Обычно получалось. Но бюджет приходилось резервировать на 2х, ну, а оплата от 1Х до 2Х. Но объем работы был меньше.
Суть не столько в языке, сколько в том, что автор не понимает, почему заказчик просил его переписать. Ну и да, при создании системы надо думать о поддержке ее другими программистами.
Заказчик от этого как раз котел уйти. Ставить на каждое место оператора i3 из-за того, что там JS — это бред.
НЛО прилетело и опубликовало эту надпись здесь
Возможно наверно. Но я ни разу такого не видел. Большинство интернет магазинов еле ворочаются у меня на i5. И там сидят хорошие программисты, а фильтр по товарам — это как-бы гораздо проще, чем отображение всего того, что нужно оператору в ERP системе.
Большинство интернет-магазинов — это не SPA. В большинстве интернет-магазинов дизайн сложнее, чем у вас. А размер базы у них не позволяет загрузить ее полностью на клиент.
И нет, фильтр в интернет-магазине (фасетный поиск) это не так просто, как вам кажется.
И нет, фильтр в интернет-магазине (фасетный поиск) это не так просто, как вам кажется.
Соглашусь, но позволю себе заметить, что говнокод на Delphi/C++ будет быстрее оного на PHP/JS (надеюсь, вы не станете с этим спорить, а если все же захочется — добро пожаловать в Performance-Test в моем ГХ). Во-вторых, большинство современных программистов навешивают такое количество overhead'a на собственно нужный код, что это потом ворочается еле-еле.
Поверьте мне, я знаю, о чем говорю — у меня третий компьютер — Raspberry Pi 3, и на нем пользоваться сайтами (большинством) настоящая боль. Недавно была нужда сделать заказ через интернет в МедиаМаркт. Я на неслабом устройстве (4ядра по 1600МГц, 2 ГБ ОЗУ) измучался, пока разместил заказ. Проклинал их программистов самыми разными проклятиями))
Поверьте мне, я знаю, о чем говорю — у меня третий компьютер — Raspberry Pi 3, и на нем пользоваться сайтами (большинством) настоящая боль. Недавно была нужда сделать заказ через интернет в МедиаМаркт. Я на неслабом устройстве (4ядра по 1600МГц, 2 ГБ ОЗУ) измучался, пока разместил заказ. Проклинал их программистов самыми разными проклятиями))
Это не требования JS, это требования той ERP. JS работал в браузерах когда никакого i3 в помине не было. Как напишете, такая и будет скорость.
НЛО прилетело и опубликовало эту надпись здесь
Справлялись, да. А теперь не справляются. У меня был нетбук с первым поколением Intel Atom N270 (1 физическое ядро 1.6GHz, 2 потока благодаря HT), 1 ГБ DDR2 RAM. В 2008 на нем можно было играть в игры, ходить в Интернет, запускать студию и т.п.
Прошло почти 10 лет, старые игры на нем вполне работают (как и старая студия), а вот в Интернет на нем лучше не ходить. Совсем.
Прошло почти 10 лет, старые игры на нем вполне работают (как и старая студия), а вот в Интернет на нем лучше не ходить. Совсем.
НЛО прилетело и опубликовало эту надпись здесь
Ну, у меня есть пет-проект, где я, по крайней мере, стараюсь.
В том числе делаю тесты на слабых устройствах.
Вот, после очередного набора оптимизаций:
290KB transfered, Finish 1.96 s, DOMContentLoaded 483 ms
И там есть куда двигаться дальше.
"http://cosmodream.ga/js-html-mycity/
is faster than the top-performing sites in the Games industry"
В том числе делаю тесты на слабых устройствах.
Вот, после очередного набора оптимизаций:
290KB transfered, Finish 1.96 s, DOMContentLoaded 483 ms
И там есть куда двигаться дальше.
"http://cosmodream.ga/js-html-mycity/
is faster than the top-performing sites in the Games industry"
Заказчик от этого как раз котел уйти. Ставить на каждое место оператора i3 из-за того, что там JS — это бред.
Бредом это является только если ваша система планировалась бы для экономии железа на 100 точках.
Для 5 точек дешевле не то что i3, а даже и i7 — по сравнению со стоимостью разработки описываемой системы
Думал, это осталось в прошлом: теплый ламповый Delphi; все эти прекрасные ":=", «TЧтоТо»; работа без тз, азарт, с которым бросаешься на задачу, не понимая масштабов трагедии и т.д. Спасибо за статью, почти как «Дискотека 90х».
Не останется это в прошлом ещё долго, если не привязываться конкретно к Delphi.
Не знаю, за что минусанули вас, но я тоже подумал о прежних временах "автоматизации" :)
И вспонимается модель зрелости процессов разработки ПО.
Уровень 1. Начальный. Производственный процесс характеризуется как создаваемый каждый раз под конкретный проект, а иногда даже как хаотический. Определены лишь некоторые процессы и успех проекта зависит от усилий индивидуумов.
НЛО прилетело и опубликовало эту надпись здесь
Есть.
Это не дельфи текст, а текст из скрипта. Перенести туда все enum и прочие кнстанты я пока не успел.
НЛО прилетело и опубликовало эту надпись здесь
PascalScript не работает под android. Точнее я не смог его заставить собраться без больших правок. Поэтому использую легковесный Pascalc. Там можно почти тоже самое.
Кстати если разбирать конкретно этот момент — эти константы задаются в базе. Поэтому их надо тянуть не через enum, я через Table.RowName что немного сложнее. Поэтому первоначальные скрипты писались используя просто константы.
А по поводу реакции заказчика — единственное его членораздельное замечание — почему приложение на андроиде запускается целых 4(!) секунды. Работает без лагов и прочих проблем, но запускается 4(!) секунды. В общем истиной причины разрыва я, к сожалению, не знаю.
Кстати если разбирать конкретно этот момент — эти константы задаются в базе. Поэтому их надо тянуть не через enum, я через Table.RowName что немного сложнее. Поэтому первоначальные скрипты писались используя просто константы.
А по поводу реакции заказчика — единственное его членораздельное замечание — почему приложение на андроиде запускается целых 4(!) секунды. Работает без лагов и прочих проблем, но запускается 4(!) секунды. В общем истиной причины разрыва я, к сожалению, не знаю.
Интересно, я один такой, кто сумел на скриншоте увидеть телефон Дарьи?
Надеюсь, что это фейковые данные.
А теперь по существу статьи: по сути и обсуждать нечего — автор перешел в своих изысканиях на второй уровень (создание скриптового языка на компилируемом + «нескучные» формы), опробовал это на бедолаге-заказчике, попутно окрестив свое творение ERP, и сейчас пытается найти хоть какое-то применение всему этому.
Могло бы быть интереснее, если бы:
Надеюсь, что это фейковые данные.
А теперь по существу статьи: по сути и обсуждать нечего — автор перешел в своих изысканиях на второй уровень (создание скриптового языка на компилируемом + «нескучные» формы), опробовал это на бедолаге-заказчике, попутно окрестив свое творение ERP, и сейчас пытается найти хоть какое-то применение всему этому.
Могло бы быть интереснее, если бы:
- было бы больше конкретики в описании кейса и причин, почему нужно было писать что-то свое;
- были описаны какие-то нестандартные подходы к архитектуре и реализации;
- были показаны сильные стороны применяемых технологий;
- и все это щедро разбавлено скринами того, как все это хозяйство конфигурируется и выглядит на разных устройствах.
ERP — это и склад с его логистикой, и учет главного ресурса всех предприятий — персонала, и учет продаж закупок, по возможности, еще и учет производства, увязывание этого всего с бухгалтерским учетом с его планами счетов и отчетностью.
Вы вначале упомянули «так как не было контроля за кухней и доставщиками» и описали учет заказов и доставки. А как же кухня? И где же ведется объединенный учет всего этого?
Вы вначале упомянули «так как не было контроля за кухней и доставщиками» и описали учет заказов и доставки. А как же кухня? И где же ведется объединенный учет всего этого?
Склад с логистикой нужен далеко не везде. В данном случае нужен учёт, что такой-то продукт заканчивается. Не более. Это настолько простая задача, что я её даже упоминать не стал. Естественно должно быть подробное описание как готовить такой-то сет или салат, так как текучку кадров ни кто не отменял, должны быть фото упакованных заказов, что бы если что не так, сразу понимать кто накосячил: кухня, упаковка или доставка. Это всё есть.
Про кухню и упаковку — это отдельные модули, которые как раз внедрялись, когда произошло расстование с заказчиком.
А ERP система это прежде всего контроль за персоналом. А потом сведение это всё в отчёты и анализ эффективности каждого объекта отчёта. Будь то сотрудники подразделения, и в целом доставка, или в целом филиал. Ну, например, когда на одном запарка и опоздания, а на другом в это время всего 3 заказа.
Вот для этого и была создана моя система.
Про кухню и упаковку — это отдельные модули, которые как раз внедрялись, когда произошло расстование с заказчиком.
А ERP система это прежде всего контроль за персоналом. А потом сведение это всё в отчёты и анализ эффективности каждого объекта отчёта. Будь то сотрудники подразделения, и в целом доставка, или в целом филиал. Ну, например, когда на одном запарка и опоздания, а на другом в это время всего 3 заказа.
Вот для этого и была создана моя система.
А ERP система это прежде всего контроль за персоналом.
Не согласен. Есть бизнесы, где персонала раз-два и обчёлся, причём этот персонал в основной деятельности на задействован, всё полностью автоматизировано.
Согласен, но я про контекст задачи. Т.е. ресторанный бизнес. Тут в основном косячит персонал. Реже проблема с закончившимися продуктами и пр. Здесь нужна автоматизация только по распределению заказов по точкам и составлению рейсов курьерам. Всё остальное — это контроль в текущем времени — решение проблем с опозданиями и недовольными клиентами которым привезли не то или не вкусное.
НЛО прилетело и опубликовало эту надпись здесь
И совершенно непонятно почему не была выбрана придуманная как раз для решения именно таких задач 1С Предприятие.
Даже реализация с нуля на этой платформе позволила бы не тратить 90% времени на решения вопросов общего характера (связи форм с данными и пр. и т.п) а сразу же перейти непосредственно к программированию непосредственно нужных бизнесу задачам.
Причем тут непонятны и позиции заказчика и позиции исполнителя. Наверное денег лишних много...
Если лет 10 назад еще был смысл писать своеобразного дублера 1С Предприятия то сейчас это целесообразно только для очень узко заточенных решений
Позиция исполнителя вполне понятна: 1С Предприятие не знает, не хочет с ним разбираться и(или) использовать. Или просто оценивает работу с 1С как менее выгодную по разным причинам.
У заказчиков бывает, что предпочитают подобные решения по двум причинам (или их комбинации): считают, что в конечном счёте своя система будет дешевле и(или) более адаптированная под их нужды. Или просто не знают об альтернативах, есть знакомый разработчик, опимали задачу, он назвал приемлемую для заказчика цену и тот соглашается. Возможно даже поинтересовавшись стоимостью подобных разработок в каких-то фирмах, которые при одинаковой оценке трудозатрат разработчика называют сумму раза в два большую, по понятным причинам.
Далеко не каждый сумеет подружить мобильные устройства (очевидно, что заказчиком требовались [почти] нативные приложения) и 1С: Предприятие. Там своё, особенное кунг-фу. А если не использовать последние достижения науки и техники, я хотел сказать, платформы 1С: Предприятия, то мы еще упремся в какие-нибудь сторонние решения типа Агент Плюс (со своим же скриптовым языком, и отдельными лицензиями на каждое клиентское устройство). И да, там тоже надо быть парнем не промах.
Стоимость лицензий Агент+ по сравнению со стоимостью самописа очень даже невелика.
Там своё, особенное кунг-фу.
Нет там никакого кунг-фу. Был по обе стороны барикад (и как android-разработчик и как 1С-разработчик) еще до изобретения в платформе «1С: Предприятие 8» такой простой и приятной штуки как HTTP-сервисы, но и тогда не было особых причин для жалоб. Сейчас несложно организовать обмен с 1С по обычным HTTP-запросам (get, post, put, delete и всеми прочими), даже формат данных можно задавать самостоятельно — XML, JSON или что-то свое (но парсинг на стороне 1С придется делать самостоятельно).
упремся в какие-нибудь сторонние решения типа Агент Плюс (со своим же скриптовым языком, и отдельными лицензиями на каждое клиентское устройство)
Что вы хотели этим сказать? Что «работу» нужно «работать»? Так нам же за это деньги платят! :)
В Агент Плюсе 1.5 применяется простой и всем известный Lua, а в двоечке действительно решили все сделать максимально как в 1С и выпустили конфигуратор, где можно точно так же как в 1С создавать новые объекты, описывать их интерфейс и писать код на 1С-подобном языке L9 (детальнее).
Вся проблема в вашей статье — это заголовок и текст, читатель вашей статьи должен быть менеджером и программистом, отсюда этот формализм в комментах и скомканость в понимании статьи. Если вы затолкали это в раздел «Управление», то зачем здесь про весь этот код, скрипты, базы. Если вы сделали крутую систему, которая разворачивает всё производство начиная от планов, позволяет при этом отбалансировать мощности, рассчитать закупку, учесть сбыт и т.д., при этом смогли все это внедрить, то это круто. И вот об этом и надо было написать. Насколько реально повысилась эффективность (просрочки стало меньше, уменьшилось ли время доставки, готовки и т.д.), насколько выросла прибыль? А если хотели про фишки разработки и про новую студию рассказать, так и надо было отдельно в разработку писать.
Обычно в таких ситуациях хуже другое, то, что сразу не видно — сопровождение и доработка. Почему все покупают обычно уже известные и готовые системы, потому что там во-первых, есть реальный кейс, как из этого получить прибыль, во-вторых — там есть лучшие практики логики, архитектуры, технологий, которые позволяют через год, два, пять не оказаться у разбитого корыта, когда очередной разработчик-одиночка потеряет энтузиазм под нагрузкой растущего бизнеса и устанет/задолбается реализовывать хотелки. При отсутствии документации, влезать в такие дебри никто не захочет. А разработка документации — это отдельный бюджет.
Ваш клиент пошел на большой риск, и ему 10 раз надо подумать, как этот риск окупить. Я не говорю, что он поступил плохо, если все риски просчитаны и эффект сопоставим, то вопросов нет.
Обычно в таких ситуациях хуже другое, то, что сразу не видно — сопровождение и доработка. Почему все покупают обычно уже известные и готовые системы, потому что там во-первых, есть реальный кейс, как из этого получить прибыль, во-вторых — там есть лучшие практики логики, архитектуры, технологий, которые позволяют через год, два, пять не оказаться у разбитого корыта, когда очередной разработчик-одиночка потеряет энтузиазм под нагрузкой растущего бизнеса и устанет/задолбается реализовывать хотелки. При отсутствии документации, влезать в такие дебри никто не захочет. А разработка документации — это отдельный бюджет.
Ваш клиент пошел на большой риск, и ему 10 раз надо подумать, как этот риск окупить. Я не говорю, что он поступил плохо, если все риски просчитаны и эффект сопоставим, то вопросов нет.
Хм… Оказался в такой же ситуации в этом году и тоже Delphi :-) Может тенденция :-))
Был на фрилансере простой заказ на CRM для предприятия, проводящего освидетельствования водителей и автотранспорта с горящими сроками. Я решил на него отозваться, т.к. заказчик был территориально рядом (обычно заказчики в Москве и не хотят работать с теми, кто не может подъехать в офис и там пообщаться, было такое много раз, после чего я перестал реагировать на такие заказы).
У меня есть готовая и отработанная платформа для ERP под win32 без веб-морды. Т.к. отработала более 10 лет, то быстрая реализация на ней всех требований по учету проверяемого автотранспорта, водителей, предприятий, всех сопроводительных документов и документов на автотранспорт и водителей заняла буквально 3-4 дня с базовой доводкой интерфейса, БД на бесплатной версии SQL Server, справочники, основной интерфейс учета, отчеты по проделанной работе. И это по нескольким от руки нарисованным листочкам заказчика, который сам не знал чего хотел, но срочно и сейчас.
Ладно, принес, начинаю показывать и тихо прихожу в ужас, заказчик мыслит на уровне блокнота, но хочет много всего и не понимает как этим пользоваться. У него начинается расхождение хотелок и необходимости понять тот достаточно простой интерфейс (таблицы и формы редактирования их содержимого с простым и понятным набором полей). Дал структуру взаимосвязей таблиц, благо база небольшая и было все достаточно прозрачно по назначению, вот тут водители, они относятся к предприятиям и они необходимы, чтобы выпустить в рейс машину, на которой они уедут после освидетельствования.
Да — структура базы в отличие от кода сразу была привязана к задачам предприятия, но это всего лишь CRM и специализированная для конкретного случая. К тому же упрощает работу по обслуживанию, мало ли что. А так все данные хорошо просматриваются.
Но ладно думаю, как-нибудь пройдет, деньги очень небольшие, мне было интересно просто сделать что-то такое. Пусть думаю поработают, система запросто может переварить под сотню рабочих мест и миллионы строк записей в реалтайме на обычных ксеонах без каких-то усилий.
Одним словом движок гораздо мощнее, чем им потребуется в обозримом будущем, а как вырастут — можно будет легко добавить любой разумный функционал.
И вот через пару дней они меня просят приехать и обговорить то что они увидели в том что я сделал, а заодно я подкрутил некоторые места по интерфейсу, постаравшись реализовать его на максимально доступном понимаю уровне.
И вот я приехал и началось — собрались абсолютно непричастные и раздались вопли — а вот хотим интерфейс как в банке! И чтобы вот тут и вот тут и вот эдак. При этом начинаем разбираться — и выясняется что они и работу в форме таблиц не понимают и взаимосвязей между сущностями, с которыми работают, до конца не уяснили.
И при этом — они нажимают на то что им срочно, они открылись, только что открылись, к ним сейчас прибежит сотня клиентов и вот сейчас надо уже всех учитывать. Тихонько интересуюсь, а сколько работаем уже — два дня, а сколько клиентов пришлось учесть при помощи ручки и бумажки, ни одного, еще ни одного клиента у них не было :-)
В общем после всех этих воплей уехал и начал задумываться, а надо ли оно мне, потраченного времени было уже в три раза больше, чем мне обещали заплатить. Но хотелось увидеть свой продукт в работе. И я продолжил, но уже без энтузиазма, понимая что их ждут проблемы. Ага, через пару дней позвонили и поинтересовались когда, хотя сроки в общем-то были оговорены(из-за всех выходных на пару дней больше). И вот тогда мне невзначай сообщили — мол уже ищут другого. Это было последней каплей. Обычно с клиентами я веду себя вежливо и никого никуда не послал. Просто моментально отказался от дальнейшей работы. Пусть теперь развлекаются со студентами (никто больше на эту сумму не согласится) и оплатой вызовов специалистов (своего админа и сервера у них не было). Что их ждет догадаться несложно.
А вот основное внедрение и поддержка моей первой версии ERP было гораздо более интересным, там действительно было активно работающее предприятие — рекламное агентство с большим (более 500 страниц) оффлайновым журналом, с жесткими требованиями к реалтайму по всем данным, отчетам и прочему. Фиксации каждой мелочи, поддержка работы нескольких предприятий (они в процессе разделились на два отдельных со своими коллективами, но база общая на едином сервере, т.к. владелец общий), работы с клиентами и основной самый сложный функционал — это верстка этого самого журнала, сначала реалтайм, чтобы каждый мог увидеть текст и графику наполнения по всем полосам, и видеть что и куда ставить — в ERP, причем вид каждой страницы в интерфейсе ERP был полностью до каждого поля идентичен журналу, вплоть до шрифтов и их размеров, пришлось долго изучать все их параметры и автоматизировать работу с ними.
А потом полностью автоматизированная верстка с учетом множества требований, вплоть до совмещения баннеров по заполнению (светлые или темные стороны баннеров вместе, причем учет и по вертикали и по горизонтали), с учетом их размеров, форматов заполнения, проданных местах в каждой полосе (сверху, снизу, в начале полосы, справа от развертки и т.д. и т.п.) и выгрузкой в Indesign где его уже выверяли и отправляли в печать. Было приятно — то что ранее делал целый отдел за день (еженедельно) а то и более перед выставкой, теперь занимало не более полчаса-часа у одного специалиста.
Проработало много лет и активно дорабатывалось на ходу. А потом оффлайн умер, а онлайн уже не требовал такой сложной верстки и там все было сделано иначе и уже не мной.
Но я не сдаюсь и работаю над следующей версией ERP :-) Вебморду обещаю прикрутить :-)
Был на фрилансере простой заказ на CRM для предприятия, проводящего освидетельствования водителей и автотранспорта с горящими сроками. Я решил на него отозваться, т.к. заказчик был территориально рядом (обычно заказчики в Москве и не хотят работать с теми, кто не может подъехать в офис и там пообщаться, было такое много раз, после чего я перестал реагировать на такие заказы).
У меня есть готовая и отработанная платформа для ERP под win32 без веб-морды. Т.к. отработала более 10 лет, то быстрая реализация на ней всех требований по учету проверяемого автотранспорта, водителей, предприятий, всех сопроводительных документов и документов на автотранспорт и водителей заняла буквально 3-4 дня с базовой доводкой интерфейса, БД на бесплатной версии SQL Server, справочники, основной интерфейс учета, отчеты по проделанной работе. И это по нескольким от руки нарисованным листочкам заказчика, который сам не знал чего хотел, но срочно и сейчас.
Ладно, принес, начинаю показывать и тихо прихожу в ужас, заказчик мыслит на уровне блокнота, но хочет много всего и не понимает как этим пользоваться. У него начинается расхождение хотелок и необходимости понять тот достаточно простой интерфейс (таблицы и формы редактирования их содержимого с простым и понятным набором полей). Дал структуру взаимосвязей таблиц, благо база небольшая и было все достаточно прозрачно по назначению, вот тут водители, они относятся к предприятиям и они необходимы, чтобы выпустить в рейс машину, на которой они уедут после освидетельствования.
Да — структура базы в отличие от кода сразу была привязана к задачам предприятия, но это всего лишь CRM и специализированная для конкретного случая. К тому же упрощает работу по обслуживанию, мало ли что. А так все данные хорошо просматриваются.
Но ладно думаю, как-нибудь пройдет, деньги очень небольшие, мне было интересно просто сделать что-то такое. Пусть думаю поработают, система запросто может переварить под сотню рабочих мест и миллионы строк записей в реалтайме на обычных ксеонах без каких-то усилий.
Одним словом движок гораздо мощнее, чем им потребуется в обозримом будущем, а как вырастут — можно будет легко добавить любой разумный функционал.
И вот через пару дней они меня просят приехать и обговорить то что они увидели в том что я сделал, а заодно я подкрутил некоторые места по интерфейсу, постаравшись реализовать его на максимально доступном понимаю уровне.
И вот я приехал и началось — собрались абсолютно непричастные и раздались вопли — а вот хотим интерфейс как в банке! И чтобы вот тут и вот тут и вот эдак. При этом начинаем разбираться — и выясняется что они и работу в форме таблиц не понимают и взаимосвязей между сущностями, с которыми работают, до конца не уяснили.
И при этом — они нажимают на то что им срочно, они открылись, только что открылись, к ним сейчас прибежит сотня клиентов и вот сейчас надо уже всех учитывать. Тихонько интересуюсь, а сколько работаем уже — два дня, а сколько клиентов пришлось учесть при помощи ручки и бумажки, ни одного, еще ни одного клиента у них не было :-)
В общем после всех этих воплей уехал и начал задумываться, а надо ли оно мне, потраченного времени было уже в три раза больше, чем мне обещали заплатить. Но хотелось увидеть свой продукт в работе. И я продолжил, но уже без энтузиазма, понимая что их ждут проблемы. Ага, через пару дней позвонили и поинтересовались когда, хотя сроки в общем-то были оговорены(из-за всех выходных на пару дней больше). И вот тогда мне невзначай сообщили — мол уже ищут другого. Это было последней каплей. Обычно с клиентами я веду себя вежливо и никого никуда не послал. Просто моментально отказался от дальнейшей работы. Пусть теперь развлекаются со студентами (никто больше на эту сумму не согласится) и оплатой вызовов специалистов (своего админа и сервера у них не было). Что их ждет догадаться несложно.
А вот основное внедрение и поддержка моей первой версии ERP было гораздо более интересным, там действительно было активно работающее предприятие — рекламное агентство с большим (более 500 страниц) оффлайновым журналом, с жесткими требованиями к реалтайму по всем данным, отчетам и прочему. Фиксации каждой мелочи, поддержка работы нескольких предприятий (они в процессе разделились на два отдельных со своими коллективами, но база общая на едином сервере, т.к. владелец общий), работы с клиентами и основной самый сложный функционал — это верстка этого самого журнала, сначала реалтайм, чтобы каждый мог увидеть текст и графику наполнения по всем полосам, и видеть что и куда ставить — в ERP, причем вид каждой страницы в интерфейсе ERP был полностью до каждого поля идентичен журналу, вплоть до шрифтов и их размеров, пришлось долго изучать все их параметры и автоматизировать работу с ними.
А потом полностью автоматизированная верстка с учетом множества требований, вплоть до совмещения баннеров по заполнению (светлые или темные стороны баннеров вместе, причем учет и по вертикали и по горизонтали), с учетом их размеров, форматов заполнения, проданных местах в каждой полосе (сверху, снизу, в начале полосы, справа от развертки и т.д. и т.п.) и выгрузкой в Indesign где его уже выверяли и отправляли в печать. Было приятно — то что ранее делал целый отдел за день (еженедельно) а то и более перед выставкой, теперь занимало не более полчаса-часа у одного специалиста.
Проработало много лет и активно дорабатывалось на ходу. А потом оффлайн умер, а онлайн уже не требовал такой сложной верстки и там все было сделано иначе и уже не мной.
Но я не сдаюсь и работаю над следующей версией ERP :-) Вебморду обещаю прикрутить :-)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как я писал собственную ERP систему и что из этого получилось