LINUX.ORG.RU
ФорумTalks

CRM и ERP не нужны, ибо не автоматизируют

 , , ,


0

1

Как некоторые из вас слышали, я уже некоторое время пытаюсь укусить локти и думаю, с какой стороны бы подступиться к нише CRM+ERP.

Существуют ли по-настоящему удобные системы совместного планирования и работы?
Энтерпрайз ERP/CRM фо отомейшн оф ё сириоз бизнес

Последний тред
Поиски вдохновения и единомышленников
я создал в том числе потому что почувствовал, что исчерпал запас новой информации, но хронически не знаю, откуда его пополнить. Удивительно, но почему-то интернет скромно замалчивает эту сферу. К сожалению, имеющиеся у меня сведения позволяют сделать вывод: готовые CRM/ERP системы не нужны. Если клиенту нужно руками вводить информацию о клиенте, обновлять его статус и писать комментарии — это не автоматизированная связь с клиентами. Это тупо ручная система организации, поскольку незначительно отличается от создания бумажных карточек клиента от руки или на печатной машинке. «Оповещения» — это те карточки, которые коллега передал мне в отдельную стопочку.

Потому можно говорить о том, что какой-нибудь мегаплан или битрикс 24 — это, по большей части, системы организации ручного труда. Почему-то лицемерные продажники не любят слово «ручной» вместо этого применяют слово «автоматизированный».

«По большей части ручного» — потому что все таки есть некоторые элементы автоматизации. Например, слежение за времяпрепровождением сотрудников — пусть ввод и весь ручной, но сбор статистики о времени активности все-таки полуавтоматический. Или генерация PDF файлика по введенным оператором значениям — это тоже полуавтоматика. Конечно, когда я вижу, как оператор три минуты пялится в экран, чтобы распечатать мне чек по уже выполеннному заказу — это не автоматизированный процесс, а полуавтоматизированный. Так и хочется сказать «недоавтоматизированный». Но давайте здесь я еще больше не соглашусь сам с собой, потому что никому на самом деле не нужен PDF файл. Особенно сейчас, когда бизнес постепенно мигрирует в электронную нишу, и максимум что нужно печатать — это чек, хотя бы потому, что так требует законодательство. А вот если на печатаемом документе еще и нужно ставить подпись/печать — это уже лишняя и бессмысленная ручная работа оператора.

Самое труднодостижимое и самое полезное в автоматизации — когда оператор перестает замечать систему. Когда руководитель вводит в компьютер «сделать трактор», а система находит нужных свободных сотрудников, ставит им задачи со сроками, резервирует детали, заготовки, инструмент на складах и заказывает недостающее. Это то, для чего изначально вообще задумывалось ERP. К сожалению, в реальном мире возникают несостыковки, брак, работник заболел/его сбил автобус, технология изменилась, склад замело снегом. Если довести эти факторы до абсурда, то получится система планирования в рамках страны, в которой форс мажоров настолько много, что планирование со сколь бы то ни было приемлимой точностью просто невозможно.

Проблемы автоматизации, как правило, находится на стыке некоторых механизмов, например: поступил звонок от клиента — передать клиента его привычному менеджеру или первому свободному, если привычный занят. Здесь есть две точки сопряжения: распознание номера телефона и определение факта доступности менеджера. Если их не проработать, то от автоматизации не остается и следа. И если у нас в системе есть N программ/механизмов, то задача их сопряжения имеет сложность O(N^2), то есть, сопрягать N механизмов с N(-1) механизмами. Отсюда вывод: плодить программы значительно проще, чем потом лепить из них единую автоматизированную систему.

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

А что же тогда продают упомянутые мегаплан, битрикс, ну и в конце-концов SAP с Oracle? Как правило, они продают число модулей, табличек, вкладочек, рюшечек на страничках. Это свойство, которое точно противоположно автоматизированности системы — незаметности модулей, которые должен видеть только админ и которые просто тихо незаметно работают. Таким образом, когда вы внедряете эти готовые программы на предприятии, вы прежде всего ВНЕДРЯЕТЕ ПРОБЛЕМУ, а потом уже ищете ей решение. Так и вижу лозунги «Битрикс 24 — лучшая проблема для вашего бизнеса», «BMW е$@^!я с SAP», «SAP — ready when you are» (вольный перевод: «SAP — будет готова как только вы подготовитесь к ней»). Последнее, между прочим, настоящий рекламный слоган, который иронично отражает сложность внедрения SAP на предприятии — а у SAP накопился богатый опыт провалов внедрений.

Как сказал один мой знакомый, который когда-то занимался вместе со мной внедрением самопального ERP на местном заводе: «нужно не спрашивать у заказчика о том, какую проблему ему нужно решить, а приходя к заказчику нужно уже иметь решения проблем, про которые он до тебя не знал». Я много лет не мог понять этой фразы. Наконец, я её понял.

Но я, все-таки, подходил к вопросу со стороны «чему можно научиться у этих систем? Как можно сделать их лучше, можно ли улучшить интерфейс и реализацию, чтобы по итогу получить конкурентное преимущество и оттяпать у них рыночек». А парадокс решения в том, что чем тоньше ваша система, тем проще она поддается автоматизации. Чем проще ваша БД, тем удобнее её адаптировать под нужды бизнеса. По этой причине SAP является самой-присамой неудобной базой для автоматизации на рынке.

Специалист по UX, Голден Кришна, написал целую книгу на схожую тему «Хороший интерфейс — невидимый интерфейс». Один из ключевых тезисов книги — нынче модно лепить планшеты куда ни попадя, хотя они делают устройство не проще, а сложнее. Именно это делают мегаплан-битрикс-SAP-Oracle — удовлетворяют потребность налепить китайский планшет на ваш бизнес (на удивление, довольно популярную потребность), превратив хорошо налаженное и много лет работающее предприятие в сиамского близнеца с четырьмя ногами. Мол «ваш бизнес приобрел больше ног, и теперь может ходить в два раза эффективнее». В тему планшетов/смартфонов они вам скажут «зато у нас есть готовые мобильные версии, удобно вне офиса ткнуть в смартфон и посмотреть список дел и сообщений». Я с удивлением обнаружил более одного человека, который занимается планированием не на компьютере и не на смартфоне, а тупо в бумажной тетрадке. Потому что бумажную тетрадку можно носить с собой и пользовательский интерфейс у нее заметно удобнее смартфона. К тому же, тетрадка не разобьется при падении на асфальт.

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

Так что да здравствует простой софт, да здравствует юникс-вей (что бы это не значило). Вот такие промежуточные итоги изучения вопроса. Странно, что эти достаточно банальные вещи мало кто пишет на просторах интернетов. Иногда кажется, что вот этот комментатор сейчас скажет то же самое — но перед ключевыми словами умолкает, будто речь идет про вопросы его мастурбации или про конечность жизни человека, о которых в приличном обществе не принято говорить вслух.

Да-я-занимаюсь-онанизмом-thread

★★★★

Ответ на: комментарий от javascript

Ничего не понял. Если лояльная аудитория схавает любой формат, то почему туда к тебе никто не придёт?

Потому что у меня нет лояльной аудитории — не ясно, что ли?

byko3y ★★★★
() автор топика
Ответ на: комментарий от javascript

А почему её у тебя нет?

А типа обязана быть? Ты не задумывался о том, что человек может не иметь желания заполучить себе аудиторию друзяшек? Зато я тебе приводил вполне конкретный пример достаточно большого поныне существующего интернет-портала sc2tv.ru, который построил свою систему общения на текстовых файлах. Но ты упорно пытаешься перевести обсуждение в русло «почему ты не танцуешь в балете?».

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

>Потому что истинная заслуга Стива Джобса заключается в том
А твоя заслуга заключается в том, что ты портишь воздух

zgen ★★★★★
()
Ответ на: комментарий от zgen

А твоя заслуга заключается в том, что ты портишь воздух

Справедливости ради — заводы Джобса и ко попортили на много порядков больше воздуха.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

построил свою систему общения на текстовых файлах.

)))) Все-таки радует, как ты регулярно расписываешь в собственной профнепригодности от треда к треду.

javascript
()
Ответ на: комментарий от byko3y

Если бы это было так, то продукты бы изменились. Если на рынке сейчас не так, значит правды в твоих словах нет.

umren ★★★★★
()
Ответ на: комментарий от umren

Если бы это было так, то продукты бы изменились. Если на рынке сейчас не так, значит правды в твоих словах нет

Ты хочешь сказать, что на рынке не применяются мелкие самопальные системы автоматизации? Да валом их. На самом деле, внедрений крупных готовых систем по количеству сильно меньше мелких наколеночных. Просто, эти мелкие наколеночные системы ничего не объединяет — никакая торговая марка, никакая франшиза.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

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

umren ★★★★★
()
Ответ на: комментарий от byko3y

Десятки тысяч записей — это примерно та границы, за которой классическая РСУБД может работать с приемлимой производительностью ТОЛЬКО по индексам

Какая ерунда.

Чек ë хендз.

Psilocybe ★★★★
()
Последнее исправление: Psilocybe (всего исправлений: 1)
Ответ на: комментарий от Psilocybe

Десятки тысяч записей — это примерно та границы, за которой классическая РСУБД может работать с приемлимой производительностью ТОЛЬКО по индексам

Какая ерунда.
Чек ë хендз

Еще один «эксперт» в треде? У какого-нибудь мускуля фулскан работает со средней производительность в вакууме порядка 30-150 записей в секунду (на MyISAM обычно заметно быстрее). Как только ты переваливаешь за десятки тысяч, то даже простые запросы начинают выполнятся порядка секунды. сложные уже будут выполняться несколько секунд, а какой-нибудь продвинутый OLAP будет чухаться минутами и часами.

Да, есть аргумент «перейти на SSD», «перейти на NVMe», «держать базу в оперативе на сервере с 2 Тб RAM», что откладывает границу скатывания производительности в N раз, но сути не меняет — это решение не масштабируется. В отличие от некоторых нереляционных и колоночных СУБД, которые с жесткого диска запросы по нереляционным индексам или фулскан по колонке делают с такой скоростью, что кажется будто это мускуль работающий с двух терабайт оперативы.

byko3y ★★★★
() автор топика

Неожиданного обновления пост. На просторах интернетов неоднократно встречаю аргумент плана «да, неюзабельно, да, тормознуто, но! Зато в $erpname уже заложены все тонкости всех законодательств мира». Мне посчастливилось не иметь дел с бюрократическим бардаком, но меня так просто не испугаешь. Я здесь не затрагиваю вопросы серой бухгалтерии. Может быть здесь кто-то имел с бухгалтерией/бюрократией дело и можешь рассказать, насколько всё плохо, насколько 1С Бухгалтерия помогает с этим разбираться, и насколько действительно сложно повторить это?

К слову, в хохлостане 1С прекратило поддержку местного законодательства, с чем я поздравляю всех счастливых украинских владельцев 1С.

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

В отличие от некоторых нереляционных и колоночных СУБД, которые с жесткого диска запросы по нереляционным индексам или фулскан по колонке делают с такой скоростью

Ух какой тред интересный, а можно названия этих СУБД?

tfeartx
()
Ответ на: комментарий от tfeartx

Ух какой тред интересный, а можно названия этих СУБД?

SAP HANA, Exasol, Greenplum, Impala, даже для постгреса разрабатывали колоночное хранение. Из нереляционных можешь брать любой проект на Lucene, в число которых входит хорошо известный ElasticSearch. Подозреваю, что ты хотел меня словить на монге, но нет — монга на текущий момент является криптореляционной СУБД со вполне реляционными индексами, на базе которых и производятся основные операции в среднем говнопроекте на средней монге.

byko3y ★★★★
() автор топика
Последнее исправление: byko3y (всего исправлений: 2)
Ответ на: комментарий от byko3y

Мне вспоминается, как я краснел, когда покупал бате новый смартфон, но не мог пользоваться его интерфейсом: тыкаю сюда. тыкаю туда, возюкаю пальцами — ноль реакции

А когда из vim выйти не мог - не краснел? Не понимаю, в чем разница.

tfeartx
()
Ответ на: комментарий от tfeartx

А когда из vim выйти не мог - не краснел? Не понимаю, в чем разница

Так мог же: killall -s SIGKILL vim

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Десятки тысяч записей — это примерно та границы, за которой классическая РСУБД может работать с приемлимой производительностью ТОЛЬКО по индексам

Я честно пытался, скипал сообщения от торвн77 и ветки про мобилы, но тут стало тяжело.

tfeartx
()
Ответ на: комментарий от tfeartx

Десятки тысяч записей — это примерно та границы, за которой классическая РСУБД может работать с приемлимой производительностью ТОЛЬКО по индексам

Я честно пытался, скипал сообщения от торвн77 и ветки про мобилы, но тут стало тяжело

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от tfeartx

Тред осилил, оп очередной душнила возраста 40+ лет, видимо (без обид).

SAP HANA, Exasol, Greenplum, Impala, даже для постгреса разрабатывали колоночное хранение. Из нереляционных можешь брать любой проект на Lucene, в число которых входит хорошо известный ElasticSearch

Ну давай забенчим «раз на раз (c)» на твоих запросах чо угодно из этого списка с постгресом на слабом железе, если уж ты против ' «перейти на SSD», «перейти на NVMe», «держать базу в оперативе на сервере с 2 Тб RAM»'.

Слушай, я не шаман, но мне кажется у тебя профдеформация. Меняй работу, пока не поздно.

Про бенчи если что шутка, надеюсь ты не серьезно противопоставлял все это СУБД.

tfeartx
()
Последнее исправление: tfeartx (всего исправлений: 1)
Ответ на: комментарий от tfeartx

Почитал соседний твой тред, все вопросы отпали. Это мощно.

tfeartx
()
Ответ на: комментарий от tfeartx

Тред осилил, оп очередной душнила возраста 40+ лет, видимо (без обид)

«Душный человек, душнила – сленговое определение неприятного, скучного, мелочного и нудного человека»

Есть же замечательное общепринятое слово «старый пердун», «душнила» же — это скорее желторотик, а не 40+. Обиделся бы я если бы ты угадал, но ты не угадал.

Зато я могу угадать, что ты из тех современных девопсов или приближенных к ним, которых не смущает необходимость ставить на сервер двадцать служб в контейнерах под управлением k8s для организации серьёзного личного бложика с котиками. То есть, основная база у нас на мускуле, кэш данных на редисе, HTTP-кэш на Varnish, полнотекст на эластике, запросы кладутся в очередь на КроликMQ и обрабатываются бэк-логикой на PHP; ну и веб-сервер на nginx, куда же без него. Кто-то улыбнулся, а кто-то в курсе, что это, в общем-то,
достаточно типовой стэк
современных проектов.

/usr/bin/run-blog my.conf? — Не, это не серьёзно, это прошлый век.

Я уверен, что ты сейчас сидишь и думаешь «что он несёт? Всё нормально с этим стэком, никто не будет по пять лет разрабатывать и оптимизировать наколенную поделку, как в ваши девяностые» — потому что ты не осознаешь, что достаточно банальный монолит на SQLite или BerkleyDB до поры до времени может вывозить 10 к запросов в секунду без какой-либо дополнительной помощи, поскольку масштабируется с ядрами процессора и потому логику под это дело можно писать даже на скриптовых языках. Особенно это касается BerkleyDB, у которой даже репликация есть.

Ты пишешь

забенчим «раз на раз (c)» на твоих запросах чо угодно из этого списка с постгресом на слабом железе

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

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

byko3y ★★★★
() автор топика
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от byko3y

Я уверен, что ты сейчас сидишь и думаешь «что он несёт?

Да, примерно так я и думаю, читая каждый твой комментарий в этом треде и в соседнем.

Я вообще не программист, не дба и не девопс. Хотя пожалуй отвечу выборочно :

потому что ты не осознаешь, что достаточно банальный монолит на SQLite или BerkleyDB до поры до времени может вывозить 10 к запросов в секунду

Это возможно, кто ж спорит? Просто у тебя задачи унылые, ты завис в своем 1с или что там мире и всех измеряешь этой линейкой. И вот ты от чего-то решил что по твоим задачам можно выкинуть остальные бд, потому что тебе они не нужны. Можно ещё выкинуть nginx, редис и все остальное. Да, для твоих задач наверное можно. Для моих нельзя. Алсо, ты пишешь это на лоре, где эластик (я запутался, сначала ты предлагал его как альтернативу, а теперь стал против?) используется для поиска.

Я знаю, что зря пишу это, т.к. прочитал 2 треда почти полностью и видел твое мнение про современный веб, современные телефоны и все прочее.

Ну, жалуйся дальше, что мир несправедлив, сиди в своем 1с болоте. Хотя

не 40+. Обиделся бы я если бы ты угадал, но ты не угадал.

даже спуфинг перерос частично свои проблемы в голове, может и у тебя получится. Желаю успеха в этом, мой комментарий не несёт негатива.

tfeartx
()
Ответ на: комментарий от byko3y

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

Да тут половина лора застала эти говнобиллинги. Вот чем чем, а этим я гордиться бы не стал.

tfeartx
()
Ответ на: комментарий от byko3y

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

Ничего себе ты Америку открыл, вау. Только не понимаешь, что постгрес юзают не только для полнотекстового поиска (хотя я бы его для этого не взял). У меня там вообще jsonb лежит пополам с text, например. Но я ж не говорю всем, что постгрес это только для json :)

Ну и да, очевидно что ты провоцируешь на корм, надо завязывать.

tfeartx
()
Последнее исправление: tfeartx (всего исправлений: 1)
  1. Для того, чтобы автоматизировать предприятие нужно сначала выяснить какие процессы существуют на предприятии, из них выявить те, что создают добавочную стоимость продукту.
  2. Ни одно сколько ни будь большое предприятие нуждающееся в автоматизации не сможет предоставить список всех процессов, не сможет отфильтровать их самостоятельно. Никогда.
  3. Ни один пограммист даже не поймёт что здесь написано.
  4. Fail.

/thread

system-root ★★★★★
()
Ответ на: комментарий от byko3y

ще один «эксперт» в треде? У какого-нибудь мускуля фулскан работает со средней производительность в вакууме порядка 30-150 записей в секунду (на MyISAM обычно заметно быстрее). Как только ты переваливаешь за десятки тысяч, то даже простые запросы начинают выполнятся порядка секунды. сложные уже будут выполняться несколько секунд, а какой-нибудь продвинутый OLAP будет чухаться минутами и часами.

Хмм, решил посчитать в БД:

Л\с: 58471161

проводок: 2415058870

Продолжай натягивать сову на глобус

Psilocybe ★★★★
()
Ответ на: комментарий от byko3y

«душнила» же — это скорее желторотик, а не 40+

Это просто зануда, от возраста не зависит.

Nervous ★★★★★
()
Ответ на: комментарий от tfeartx

Я вообще не программист, не дба и не девопс

Ты просто сочувствующий и солидарный? Так что ж ты мне голову морочишь с таким умным лицом?

ты пишешь это на лоре, где эластик (я запутался, сначала ты предлагал его как альтернативу, а теперь стал против?) используется для поиска

Эластик — это быстрое костыльное решение, которое само по себе много чего умеет из коробки, но, как правило, множество этого «многого» слабо пересекается с потребностями поиска конкретного проекта, и если проекту нужен хороший поиск, то берется что-то более интегрированное и расширяемое.

byko3y ★★★★
() автор топика
Ответ на: комментарий от tfeartx

Ничего себе ты Америку открыл, вау. Только не понимаешь, что постгрес юзают не только для полнотекстового поиска (хотя я бы его для этого не взял). У меня там вообще jsonb лежит пополам с text, например. Но я ж не говорю всем, что постгрес это только для json

Так если ты это понимаешь, почему тогда в предыдущем раунде сообщений писал ровно наоборот? Кто там кого на корм провоцирует?

byko3y ★★★★
() автор топика
Ответ на: комментарий от system-root

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

I know that feel, bro. Наверное, я не программист, потому что понимаю. Именно по этой причине никакой SAP/Oracle/IBM/Netsuite/Мегаплан/Bitrix не налезут ни на одно реальное предприятие, потому что реальное предприятие неуловимое и изменчивое. Именно поэтому нужно решение, которое создает наименьшее число ограничений на работу. Именно поэтому SAP — худшее решение на рынке, поскольку создает настолько много ограничений, из-за чего внедрение либо растягивается и становится очень дорогим, либо вообще проваливается, поскольку всё это время бизнес стоит без автоматизации, и не может ждать, пока интегратор доведет систему до ума спустя еще $100 млн и пять лет. В 100% случаев интегратор и SAP винит во всём заказчика.

Парадокс в том, что маркетинг SAP как раз основан на том, чтобы вытрусить как можно больше денег из заказчика, при этом имея безупречное оправдание для этого, мол «наша система самая мощная в плане фич и конкурентов в этом у нас нет».

В реальности бизнес-процессы не только «не получилось выяснить» — их невозможно выяснить в принципе, поскольку они в большой компании разные для разных людей и отделов, и, более того, они регулярно меняются.

byko3y ★★★★
() автор топика
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от Psilocybe

Л\с: 58471161
проводок: 2415058870
Продолжай натягивать сову на глобус

И к чему ты мне это выдал? Ты хочешь мне сказать, что вот это функционирует не по индексам?

byko3y ★★★★
() автор топика
Ответ на: комментарий от Psilocybe

криптореляционной СУБД со вполне реляционными индексами

Новое слово в теории БД от иксперда ЛОРа

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

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

Неожиданного обновления пост. На просторах интернетов неоднократно встречаю аргумент плана «да, неюзабельно, да, тормознуто, но! Зато в $erpname уже заложены все тонкости всех законодательств мира». Мне посчастливилось не иметь дел с бюрократическим бардаком, но меня так просто не испугаешь. Я здесь не затрагиваю вопросы серой бухгалтерии. Может быть здесь кто-то имел с бухгалтерией/бюрократией дело и можешь рассказать, насколько всё плохо, насколько 1С Бухгалтерия помогает с этим разбираться, и насколько действительно сложно повторить это?

Так что, никто не подскажет?

byko3y ★★★★
() автор топика
Ответ на: комментарий от byko3y

их невозможно выяснить в принципе

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

Очевидно, что причинить благо заказчику менее выгодно чем впарить SAP like ерунду.

system-root ★★★★★
()
Ответ на: комментарий от system-root

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

Практика показывает, что выяснить конкретные бизнес-процессы можно в единственном случае — если ты их унифицировал. То есть, не ты адаптировался под фирму, а ты адаптировал фирму под выдуманные бизнес-процессы. Посмотри, сколько людей даже в этом треде по сути написали именно об этом, вроде «бардак нельзя автоматизировать» и тому подобное.

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

Вроде меня, когда меня натягивают на Jira — работа программиста по большей части слабо налазит на «палочную систему». Да, работа оператора-продавца на нее налазит чуть лучше, но все равно плохо.

Мне доставляет некоторое извращенное удовольствие осознание того факта, что продавец интернет-магаза, в котором я делаю заказ, рвет волосы на голове от того, что я заплатил неверную сумму и доплатил после этого (им не нужны лишние деньги?), но продавцу при этом проще оформить заказ на меньшую сумму, поскольку их «глобус» вообще не допускает шага влево-вправо, сума должна быть уплачена однократно, рубль к рублю, или так же в полном объеме возвращена. Если платеж делается в два захода — это уже error: arithmetic overflow or string truncation, invalid value in key field.

То есть, системы проектируются так, что если продавцу захотелось отойти в туалет покакать — он должен заполнить форму «покакать, с 10:23 до 10:27». А если у продавца случается понос, то система встает колом, потому что продавцу идут вызовы, а его нет на месте. Как писал выше Shadow, грамотный интегратор добивается у начальника, чтобы начальник строго штрафовал сотрудников за понос в рабочее время. Рабочее время закончится — дрищи сколько влезет, но в рабочее время будь добр иметь нормальный стул.

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

byko3y ★★★★
() автор топика
Последнее исправление: byko3y (всего исправлений: 2)
Ответ на: комментарий от byko3y

И к чему ты мне это выдал? Ты хочешь мне сказать, что вот это функционирует не по индексам?

Несостоятельность твоей оценки

Как только ты переваливаешь за десятки тысяч

Psilocybe ★★★★
()
Ответ на: комментарий от byko3y

Ты можешь взять слово «реляционный» в скобки, поскольку в

Налицо несостоятельность используемой терминологии

а ведь индексы самые разные бывают

и чо? При чем тут реляционные СУБД?

Но у тебя существует только «начальник сказал мускуль — значит мускуль».

Фантазии полезли, что говорит о несостоятельности аргументации.

Psilocybe ★★★★
()
Последнее исправление: Psilocybe (всего исправлений: 1)
Ответ на: комментарий от Psilocybe

Ты можешь взять слово «реляционный» в скобки, поскольку в

Налицо несостоятельность используемой терминологии

Как только ты переваливаешь за десятки тысяч

Несостоятельность твоей оценки

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

byko3y ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.