Данный раздел форума называется "ERP и учетные системы".
Я занимаюсь внедрением и настройкой учетных систем, продукт не коробочный с кучей недостатков и очень непростой. Часто пересекаюсь с различными версиями 1С (что то в ней понимаю). Основное, что мне приходится решать это настройка системы на бизнес клиента (по опыту работы с 1С там тоже).
Есть некий стандартный функционал, который надо заставить работать (подстроить, оптимизировать и тд...). Работа крайне тяжелая и нервная, с тьмой нюансов (требуется быстро разобраться в бизнесе клиента и решить его проблему). Тут постоянно встречаются упоминания о средствах которые поставил и все работает независимо от бизнеса или настройка займет всего ничего...
Может я от жизни отстал???

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

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

Решения предлагаются за смешные деньги... Может у меня запросы слишком высокие???
(Разработчик стоит минимум 1500, желательно на штуку больше, что б фигню не сотворил)

Пред История: Система Прагматика являлась достаточно эффективным ПО для компании дистрибьютера. Разработана в середине 90 и для того времени очень грамотно и эффективно. Основной разработчик Андрей Копенкин, разработка бизнес операций Директор Прагматика. Система работала на основе Access97 (разрабатывалась еще на 2), в архитектуре файл сервер (есть несколько мест, где она до сих пор так работает). Я познакомился с системой в компании Бюрократ, где участвовал в проекте по переводу системы на SQL сервер (технологическое обеспечение, ПО переводил Андрей Копенкин), вводу новых операций и поддержке системы. К сожалению, произошел конфликт с руководством ИТ отдела и я вместе со вторым разработчиком системы Игорем Герухой покинул Бюрократ. Игорь осуществил перевод системы Прагматика на SQL сервер и должен был начать разработку новых схем операций, я должен был обеспечить стабильность системы, но Игорь тяжело заболел. В итоге кроме обеспечения стабильность, под руководством Директора Прагматика стал заниматься разработкой новых операций (у меня были совершенно другие планы). Начало работы по переводу декабрь 2000, мой приход февраль 2001, начало разработки апрель.

Основное в создании новой бизнес схемы, был «Отдел Обслуживания» (ОО).
Неважно кто создал счет и для какого клиента. При наступлении необходимых условий происходит автоматическая отгрузка (оплата, наличие товара и прочее…). Подход и создание ОО (такого) является «Ноу-Хау» Прагматика и я не видел, что бы где-то еще, это было востребовано (в том же объеме). Операторы компании работают по отгрузкам на полном автомате, и это позволяет выполнять цель «Доставка на следующий день после заказа».
Система каталога (именования товара и бумажный носитель, распространяемый по клиентам) позволяет быстро и с минимальным количеством ошибок создавать счета (не ПО, бизнес схема).
Первая итерация потребовала месяца работы и в дальнейшем постоянно доводилась до совершенства.

Вторым этапом было создание схемы работы склада и логистики и их реализация в системе. Созданная схема оказалась универсальной и легко настраиваемой (с незначительными модернизациями применяется во многих местах), правда с первого раза не удалось разработать «удаленный склад». Вся работа заняла месяц и была готова и протестирована в июне (спустя 6 месяцев я создал макет «удаленного», но в прагматике он так и остался макетом и применялся только для работы с системой логистиков отвечающих за разработку маршрутов по доставке накладных (они из дома работали)).

Третий этап был в создании стандартов на обслуживание системы и ее поддержку. Были созданы простые инструкции, решающие большинство вопросов возникающих при эксплуатации и нанят и обучен, администратор системы, способный решить эти задачи (мелкие доработки и создание новых отчетов и запросов входили в обязанности (3 месяца)).

Четвертым этапом (после того как я замотался решать проблемы с сетью и виндусом) стали стандарты на работы с железом, сетью, ПО и мотивация системного администратора следовать этим стандартам. Для осуществления данного действа мне пришлось занять должность начальника ИТ отдела (основной этап занял 3 месяца).

Пятый этап заключался в оптимизации ПО. Этап перманентно продолжался все время моей работы в компании, в свободное время (перевод запросов в хранимые процедуры, оптимизация хранимых процедур и вьюшек, индексы, «уборка мусора» из клиента и прочее).
Реализация данных этапов была основным в моей деятельности в компании. Естественно было реализовано еще много различных операций, одной из последних стали (знаменитые) «Агентские» (ввод декабрь 2002). Многим показывал, все делают круглые глаза и начинают креститься… (по масштабности и простоте тоже уникальна (используется только там)). В январе 2003 я ушел в отпуск за свой счет (на 3 месяца), по возвращении зашел к Директору, узнал, что не нужен и написал заявление.
Причины: Первая, система превысила уровень сложности, и дальнейшие разработки делать в рамках ИТ отдела компании было не эффективно. Вторая, были наняты консультанты (на ускорение разработки), на борьбу, с которыми я тратил больше времени, чем на все остальное (реализация того бреда, который они предлагали, привела бы к существенному падению стабильности системы (и привела)). Да и не приятно когда постоянно пытаются подставить…
Итоги Сотрудничества: Оборот вырос в 10 раз, рабочих мест стало в 3 раза больше (90), ИТ отдел 4 человека (я, админ системы, админ базы и дедушка программист (очень, очень хороший)).
Отношение ко мне: Малость кинули с деньгами при расчете последней зарплаты (мелочь, но неприятно), через 3 месяца обвинили в сокрытии документации (все создаваемые процессы имели схему и инструкцию + по возможности все комментировалось как в коде так и в описаниях (собственно я и ушедший следом дедушка могли сами разобраться в чужом коде (унаследованного кода было просто немерено))), еще через пол года в том что пытался продать кому то клиентскую базу (кто-то позвонил и сказал, что я ему это предлагал, но так дорого, что он решил пожаловаться… обидно было, когда директор с легкостью поверил в эту чушь).
Система в Прагматике: После того, как я перестал вставлять палки в колеса прогресса, было быстро сделано несколько разработок. ПО заглючило и все существенные разработки (связанные с интеграцией новой бизнес логикой) были прекращены (не удалось даже создать удаленный склад (имея работающий макет, проблему решил сис админ поставив терминал сервер)). Консультант (став начальником ИТ) убедил руководство, что все станет хорошо, когда они перенесут всю логику с Access на Microsoft.NET, наняли кучу студентов и пашут не разгибаясь.
Стабильность системы успешно решалась до осени 2005 года, но начальник ИТ решил уволить админа базы, нехорошо, когда один человек обслуживает 200 пользователей и тестирует (что студенты наваяют) и программирует и отчеты и запросы внедряет (наверно возник вопрос, чем занимаются остальные…). И уволили, дела человек сдавал 1 час…
Мой опыт: Основным в успешной деятельности компании является совершенство операций, имея хорошо отлаженные операции можно развиваться даже в Excell.
Конвейер, несмотря на кажущуюся привлекательность, имеет серьезные недостатки, основной (для меня) это перенос акцента с эффективности труда людей на эффективность операций (отдельные операции могут быть очень успешные, но в случае сбоя или усложнения…).
Создание автономной (от разработчика) системы, большой риск...

LSV
1. Я не конкурирую с 1С, более того я ее активно использую!
2. Любая сложная конфа в 1С, без хорошего разработчика живет ничтожно мало(1С в некотором роде, можно считать средой быстрой разработки, типа MS Acceess).
3. В той компании мне представился шанс поддерживать самописную налоговую систему (по политическим мотивам), с тех пор я активный сторонник 1С.

Проба сил Интересноandbary - А сколько вообще может стоить клиентская база??? Клиентская база не стоит ничего... Может быть некоторую стоимость имеют контакты, но очень маленькую... На рынке полно клиентских баз, белых, чистых и актуальных-Адрес Москва, Желтые страницыи тд, черных тоже до фига...
Ценность могут иметь цены клиентов и объем с ассортиментом товара который они закупают...
В принципе я согласен... с тем что клиентская база не представляет ценности.
Цены и обьемы клиентов практически полуоткрытая информация. Она особо не афишируется, но и не имеет особого смысла сильно ее защищать (в налоговую вы ее подаете в С/Ф). (Многие имеют открытые прайсы с указанием объема и скидки). Я знаю несколько рынков и везде цены и объемы участников известны (примерно).
Всегда тайна за семью печатями, цены и условия поставщиков.

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

Проба сил andbaryОсновное в создании новой бизнес схемы, был «Отдел Обслуживания» За один месяц создать конвеер, почему так быстро? Руководство очень серьезно готовилось к этому. Технически это вылилось в создание одной новой формы позволяющей осуществлять отгрузки "на автомате" (товар есть в достаточном количестве на складе, клиент оплатил или имеет кредит, клиент готов принять товар в нужный день) (и поправлена логика работы с заказом клиента).
Вся информация в системе существовала и нужно было ее только правильно представить. Организационно к этому готовились 2 года. Был выпущен каталог и создана система работы с ним (распространен по очень многим организациям), было проведено разделение труда (создан отдел ОО), все процессы были прописаны и утверждены.
Еще месяц утряски (нужно было привыкнуть работать по новому) и по готовности системы склада процесс пошел в полную силу (резко увеличились отгрузки).

Вопрос в уровне разделения и уровне организации. Так или иначе разделение всегда существует, для этого люди и работают в организациях

По аналогии с реальным конвеером есть следующие недостатки:
1. Идеально когда работник крутит "одну гайку" - Требуется разбить процесс на очень простые шаги, что не так просто.
2. Необходимо вводить контроль качества уровня "закрутки гайки" - Ввод стандартов на работу и структуры занимающейся контролем за выполнением этих стандартов.
3. Гайки должны быть стандартного размера - Операция должна быть стандартной и должен быть кто то кто будет решать нестандартные ситуации!
4. Конвеер нуждается в обслуживании бригады высококвалифицированных ремонтников (и дорогих иначе встанет).
5. При изменении технологии требуется изменение операций (перехвод конвеера на другую модель весьма затратная операция) - В бизнес операциях это не менее затратно, но встречается чаще.
6. Люди не любят работать на конвеере.

Это недостатки... Чем можно заменить напишу позже...
PS Некоторые из пунктов можно (в принципе) объеденить (в некоторых организациях они объедены), мне показалось такой порядок более показательным (есть детали...).

Если посмотреть на передовые методики, используемые на крупных заводах, то можно заметить что конвейер постепенно заменяется (с автоматизацией всех рутинных операций) на некий участок управляемый достаточно квалифицированным инженером (тяжело назвать просто оператором) способным в достаточно большой степени самостоятельно принимать решения в зависимости от обстановки. Инженер, находящийся на этом месте, либо соглашается с предложенной ему системой схемой, либо вносит в нее изменения.
Если посмотреть на работу оператора (к примеру, той же компании Прагматик (канцелярия для офисов)), то когда клиент делает заказ, оператор узнает, что за клиент, находит клиента, вбивает позиции, определяет дату отгрузки и оформляет комплект документов. При идеальной автоматизации, оператор производит следующие действия: «Здравствуйте, Павел Сергеевич, рады вас слышать. Вам как обычно?», если как всегда, то нужно нажать кнопку, нет узнать, что изменилось и внести изменения и нажать кнопку…

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

Работавшийболее гнусной системы я нигде ни видел, полный бред с диким количеством галочек и окошек...
1. Не очень хорошо хаять упирая на сложность систему работодателя, они вас все таки нанимали с расчетом что вы с легкостью сделаете еще больше "галочек"
2. Прагматик работает со своей системой и если эти "галочки" не так стоят это может привести к тому, что люди потеряют деньги и время (конкретно). Поэтому к ним нужно относиться с большой осторожностью (на них весят реальные бизнес операции и там 300 человек ставит эти галочки).
3. Нехорошо орать на бедных программистов, собственно это проблема начальника ИТ и плохо что он не взял на себя эти разборки... (а уж потом наорать на подчиненных )
ЗЫ На меня тоже один раз так орали (на меня, а не на подчиненных (собственно я тоже напряг голос)), честно скажу был виноват, не смог в простой и доступной форме обьяснить (не техническому специалисту) почему я игнорирую его распоряжения... (потом извинился за не адекватное обьяснение )

Проба сил andbaryКонвейер, несмотря на кажущуюся привлекательность, имеет серьезные недостатки, основной (для меня) это перенос акцента с эффективности труда людей на эффективность операций... А что может заменить конвеер? Я вот смотрю и ничего не вижу... Разве хоть одна крупная контора может работать без разделения труда?
То что написал "работавший" это типичные проблемы сложного конвеера...
За простотой операций стоит сложная (и зачастую громоздкая) схема. Для того что бы эффективно работать с подобными системами требуется очень высокая квалификация (проблема даже не в деньгах, специалистов (ответственных квалифицированных и тд) не так много).
Очень тяжело и сложно строить новые процессы, по большому счету все сводится к новым галочкам и всплывающим окошкам. Сдесь обсуждалась очень серьезная тема Реинжиниринг бизнес-процессов . Для существенных изменений просто необходимо это делать. К сожалению, у меня просто не было опыта и ресурсов на эту операцию, вот и получилось, что процессы уже новые а в ПО остались куски старых диким образом связанных с новыми. Долгое время, я с этим боролся (очищая систему от мусора), потом понял, что новые "галочки" появляются быстрее...
("галочки" не только в по, они в привычках людей, в инструкциях по работе...)