[ОТВЕТИТЬ]
25.01.2017 16:18
~Guest~
 
Цитата:
Nitro Junkie FinSoft

Тут есть еще один нюанс. Перейти с Ready-to-go, а тем более Custom-made, на другой Ready-to-go - очень тяжело.
За мою практику таких примеров масса. Переходы с 1С на СуперМаг, Переходы с Раруса на Астор, переход с СуперМаг на Астор (такой один знаю). Переход с 1С самописной на SAP и т.д. и т.п.

При переходе все понимают, что часть привычной функциональности будет потерян.
25.01.2017 16:22
Nitro Junkie
 
Дело не в этом. При форсировании перехода на другое решение неизбежен саботаж со стороны сотрудников. И с аргументом "у нас раньше было так, и мы считаем что только так правильно" вы ничего не сделаете. Единственный вариант, если вы спасли руководству жизнь, а те в свою очередь спасли жизнь учредителям. :)

Custom-made в этом смысле куда более жизнеспособен, но для этого нужна IT-компания a) работающая по Agile , б) с большим опытом таких "переводов" (грубо говоря не меньше 4 крупных проектов), в) хотя бы с базовой компетенцией в данной области (а желательно глубокой). Только в этом случае риски станут адекватными. А в идеале конечно желательно чтобы финансовые риски на себя взяла эта IT-компания, но это уже большая редкость.
25.01.2017 16:27
Nitro Junkie
 
Цитата:
~Guest~ При переходе все понимают, что часть привычной функциональности будет потерян.
Повезло вам с "понимающими" пользователями. Я знаю когда при нажатии 2-кнопок вместо одной, истерики вплоть до звонков руководству, что в новой системе "невозможно работать", и возвращайте старую.
25.01.2017 16:31
~Guest~
 
Цитата:
Nitro Junkie Повезло вам с "понимающими" пользователями. Я знаю когда при нажатии 2-кнопок вместо одной, истерики вплоть до звонков руководству, что в новой системе "невозможно работать", и возвращайте старую.
Здесь упоминался персонал принимавший решение :) Никак не пользователь, который "своей" кнопки не нашел :)
В Питере дело было, новый дирекор магазина жаловалась, что не нашла кнопки "обнулить минусовые остатки" в СуперМаг Плюс, а вот на прошлом месте работы, такая кнопка была и существенно упрощала жизнь магазина. Уволили ее.
25.01.2017 16:35
OlegON
 
Цитата:
Nitro Junkie вы ничего не сделаете
когда был внедренцем, такое ломал на раз доводом, что решение принял директор, к нему и топайте, а я тут по принуждению своих шефов, и чтобы помочь вам удержаться, поскольку тех, кто не сдаст экзамен по программе, пинком под зад попрут через месяц.
25.01.2017 16:37
Nitro Junkie
 
Цитата:
~Guest~ Здесь упоминался персонал принимавший решение :) Никак не пользователь, который "своей" кнопки не нашел :)
В Питере дело было, новый дирекор магазина жаловалась, что не нашла кнопки "обнулить минусовые остатки" в СуперМаг Плюс, а вот на прошлом месте работы, такая кнопка была и существенно упрощала жизнь магазина. Уволили ее.
Ну была бы старый директор, выкинули бы СуперМаг Плюс. (в этом и особенность - кредит доверия по определению выше у тех кто был до, а не кто хочет быть после)

Ну и понятно что "обнулять минусовые остатки" идиотизм, но у нее могла быть раньше кнопка "хитрый автоматический пересорт по каким-нибудь группам" и что дальше было бы?
25.01.2017 16:39
Nitro Junkie
 
Цитата:
OlegON когда был внедренцем, такое ломал на раз доводом, что решение принял директор, к нему и топайте, а я тут по принуждению своих шефов, и чтобы помочь вам удержаться, поскольку тех, кто не сдаст экзамен по программе, пинком под зад попрут через месяц.
А как вы боролись с тем, что человек пойдет к директору, которому доложат что решение - г... И будет слово сотрудника, с которым директор работал годами, против слова продажника, который говорил, что "все будет зашибись".
25.01.2017 16:41
~Guest~
 
Цитата:
Nitro Junkie А как вы боролись с тем, что человек пойдет к директору, которому доложат что решение - г... И будет слово сотрудника, с которым директор работал годами, против слова продажника, который говорил, что "все будет зашибись".
Да ну бросьте глупости. Люди принимающие решение понимают, что ломка будет. Бывает смена решения помогает и снизить воровство.
В моей практике были откаты обратно, после покупки, но это опять же, временный путь, поменяли персонал и вперед по новой систему натягивать.
25.01.2017 16:43
Nitro Junkie
 
Но вообще понятно что под все хотелки никто подстраиваться не будет. Общемировая статистика это где-то:
33% решения подстраивается под сотрудников, 33% сотрудники подстраиваются под решение и 33% - компромисы. Чтобы заставить сотрудников на 100% подстроиться под решение, нужны ну очень крутые продажники, то есть с откатами, "запугиванием" и всеми делами (хотя стоит отметить, что к примеру у того же сервис плюса с этим проблем никогда не было :) )
25.01.2017 16:45
Nitro Junkie
 
Цитата:
~Guest~ поменяли персонал
Это же насколько важной должно руководство считать свою IT-инфраструктуру, чтобы так легко принять решение, а не поменять ли нам весь персонал. Впрочем если оно действительно так считает, тут custom-made без вариантов.
25.01.2017 17:06
~Guest~
 
Цитата:
Nitro Junkie Это же насколько важной должно руководство считать свою IT-инфраструктуру, чтобы так легко принять решение, а не поменять ли нам весь персонал. Впрочем если оно действительно так считает, тут custom-made без вариантов.

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

За 10 лет в С+ историй было масса.
25.01.2017 17:08
FinSoft
 
Цитата:
Nitro Junkie Повезло вам с "понимающими" пользователями. Я знаю когда при нажатии 2-кнопок вместо одной, истерики вплоть до звонков руководству, что в новой системе "невозможно работать", и возвращайте старую.
А часто бывает, что пользователь прав в этом случае...

Отличную помощь в переходах оказывает наличие в системе аудиторского следа. Если откровенный саботаж и говорят, что программа неправильно считает ("вчера у нас был такой результат, сегодня другой, а мы ничего не делали"), то можно легко выяснить причины.

Контрольный выстрел в голову. У С+ или Астора есть аудиторский след? Можно, например, восстановить измененную накладную на какую-то дату или показать, что изменилось за промежуток времени?
25.01.2017 17:14
~Guest~
 
В Супермаге есть. Вплоть до того, кто, с какой машины и во сколько эту операцию провел.
Там есть более продвинутая штука, чтобы не бороться с последствиями, а работать на перспективу. Административный модуль с настройкой прав, возможностей и проверок действий пользователя.
25.01.2017 18:09
FinSoft
 
Мы правильно понимаем друг друга? То есть я могу, к примеру, запросить изменения, сделанные за последнюю неделю в накладных прошлого месяца, С+ выдаст список этих накладных с детализацией по измененным строкам, что было на начало недели и стало на конец (количество, цена, товар)?
25.01.2017 18:13
FinSoft
 
Хотя, уклонились от темы. Можно не отвечать...
25.01.2017 18:42
bob
 
Цитата:
FinSoft Мы правильно понимаем друг друга? То есть я могу, к примеру, запросить изменения, сделанные за последнюю неделю в накладных прошлого месяца, С+ выдаст список этих накладных с детализацией по измененным строкам, что было на начало недели и стало на конец (количество, цена, товар)?
да. можно. но без детализации.
25.01.2017 19:33
FinSoft
 
В детализации весь смысл... Я имел ввиду хранение истории изменения записей в базе данных с возможностью их последующего анализа, доступного обычным пользователям. Например, изменили в строке документа количество отгруженного товара, можно щелкнуть на ней и увидеть, когда кто создал эту строку, какое количество ввел вначале, кто когда потом поменял эту строку, какое новое количество установил, и так по всем реквизитам. И так по всем документам, справочникам. Потом высокоуровневые отчеты и обработки на базе этого...
25.01.2017 20:31
bob
 
Цитата:
FinSoft В детализации весь смысл... Я имел ввиду хранение истории изменения записей в базе данных с возможностью их последующего анализа, доступного обычным пользователям. Например, изменили в строке документа количество отгруженного товара, можно щелкнуть на ней и увидеть, когда кто создал эту строку, какое количество ввел вначале, кто когда потом поменял эту строку, какое новое количество установил, и так по всем реквизитам. И так по всем документам, справочникам. Потом высокоуровневые отчеты и обработки на базе этого...
Не вижу особого смысла, если грамотно распределены роли. Накладная не так часто дергается из статуса принят полностью. Его может откатить для редактирования только один человек в магазине. причем правильно, если он делает это по служебной записке, где прописаны все изменения. В случае каких-то проблему у нас отвечает бухгалтер, который поставил свою метку, что он проверил накладную и принял ее полностью. вся история изменений статусов документов и кто и когда ее редактировал хранится.
25.01.2017 20:38
OlegON
 
Детализацию и отчеты можно сделать с помощью фичи СУБД - FGA. Даже включать и исключать по каким-то условиям и прочее. Вопрос в невостребованности такой фичи для аудитории этого софта. Если хранить все изменения с соответствующими аттрибутами на сетевом магазине с кучей народа, база распухнет до невообразимых размеров очень быстро.
25.01.2017 20:56
Crush
 
А, вообще, правильнее всего сделано в буржуйских системах. Там проведенный документ ни при каких обстоятельствах корректировать нельзя. Хотите изменить количество - создавайте сторнирующий документ.
25.01.2017 21:19
~Guest~
 
Причем если мне не изменяет память, данные по изменению документа доступны по каждому без шаманства.
Следовательно долгих разборок не будет, с учетом четких ролей и проверок, жесткого логирования операций, с доступностью инфы по документам, кто, где и когда.
Роли распределяются в соответствии с должностями. В случае форс мажора, кто-то зашел не со своего места, не под своим логином и решил устроить сладкую жизнь, всегда можно отследить, где это произошло, как минимум место "преступления" и запретить в ролях эту операцию, если например рабочее место доступно для множества сотрудников.

Идею бороться в первопричиной в СуперМаге Плюс - полностью поддерживаю. В итоге на вопросы некоторых клиентов, а как с вот этим борьба идет, бывали недопонимания, а зачем с этим бороться? нет причины, нет следствия.
25.01.2017 21:23
~Guest~
 
Цитата:
Crush А, вообще, правильнее всего сделано в буржуйских системах. Там проведенный документ ни при каких обстоятельствах корректировать нельзя. Хотите изменить количество - создавайте сторнирующий документ.
Только хотел об этом написать, но потом подкорректировал комент, т.к. об этом речь не шла.
Так вот, клиентов, желающих как в буржуйских системах - каждый второй.
СуперМаг Плюс может поддерживать полный запрет на работу задним числом - это всего лишь настраиваемое право, причем по ролям, т.е. у кого то может быть, у кого-то нет. Равно как и можно запретить редактировать действующие документы :)

В итоге ни один, ни один клиент на это не согласился в действительности! Потому что это Россия :))) Если бы наши поставщики были дисциплинированы, равно как и сотрудники, которые день в день принимали бы документы - вопросов бы не было.
Но даже у себя в компании, даже пытаясь хотя бы в электронном виде получать документы как можно быстрее (скан), ерунда выходит. Все ровно только в одном случае, когда мы работаем с компанией в системе электронного документооборота. А в остальных - человеческий фактор, когда иногда ошибку в документах приходится неделями выяснять.

Дебиторка по первичке - это гемморой всех видов бизнеса. Сейчас некоторые покупатели идут другим путем: сначала весь пакет документов, потом только товар и только потом оплата. Хотя и этот путь не избавляет от проблем, т.к. приход товара и первичный документ - не всегда совпадают :))
25.01.2017 21:30
bob
 
Цитата:
Crush А, вообще, правильнее всего сделано в буржуйских системах. Там проведенный документ ни при каких обстоятельствах корректировать нельзя. Хотите изменить количество - создавайте сторнирующий документ.
Есть у нас Navision в Библиоглобусе. Ничего хорошего в российской действительности.
25.01.2017 23:00
FinSoft
 
Цитата:
OlegON Детализацию и отчеты можно сделать с помощью фичи СУБД - FGA. Даже включать и исключать по каким-то условиям и прочее. Вопрос в невостребованности такой фичи для аудитории этого софта. Если хранить все изменения с соответствующими аттрибутами на сетевом магазине с кучей народа, база распухнет до невообразимых размеров очень быстро.
У меня противоположный опыт. У нас такой функционал был с самого начала, разрабатывался еще в 2004 году. Я уже настолько привык, что не понимаю, как может существовать учетная система для бизнеса, в которой все ходы не записаны. Честно, ощущение работы вслепую. Функционал в реальной жизни востребован более чем. У нас продвинутые пользователи пользуются самостоятельно. А уж при разборе полетов вещь незаменимая, позволяющая экономить массу нервных клеток.

Одно дело иметь какой-то инструмент, другое дело реальное работающее решение. Ms тоже анонсировало подобный инструмент в sql 2016, позволяющий логировать операции с базой данных без использования триггеров. Даже одинэсники включили поддержку версионирования в свою платформу, а во флагманской конфигурации УПП сделали попытку внедрить реальный функционал. Но у них все грустно с этим из-за специфичности используемой технологии...
Если с самого начала развития системы полноценный аудиторский след не был предусмотрен, то, когда появится большой слой прикладного функционала, включить это уже затруднительно.

Олег, ты прав, что лог растет быстрее основной базы. Я тоже когда-то опасался этого, предусмотрев возможность его отключения в параметрах программы. Но так ни разу и не воспользовался этой функцией. У нас используется транзакционный принцип организации лога, подсмотренный в одной старой западной системе. Сохраняемая информация минимизирована. Плата за это - более сложная схема извлечения, раскрутка, начиная с момента создания записей. Но главное, это разделение лога на рабочую часть и архивы. Это позволяет держать в модифицируемой таблице лога минимум информации, с момента создания последней резервной копии базы данных (одновременно информация переносится из оперативного лога в архивы). Архивы лога хранятся отдельно от основной базы данных, поэтому на производительность системы влияние не принципиальное.
25.01.2017 23:17
FinSoft
 
Цитата:
~Guest~ Только хотел об этом написать, но потом подкорректировал комент, т.к. об этом речь не шла.
Так вот, клиентов, желающих как в буржуйских системах - каждый второй.
СуперМаг Плюс может поддерживать полный запрет на работу задним числом - это всего лишь настраиваемое право, причем по ролям, т.е. у кого то может быть, у кого-то нет. Равно как и можно запретить редактировать действующие документы :)

В итоге ни один, ни один клиент на это не согласился в действительности! Потому что это Россия :))) Если бы наши поставщики были дисциплинированы, равно как и сотрудники, которые день в день принимали бы документы - вопросов бы не было.
Но даже у себя в компании, даже пытаясь хотя бы в электронном виде получать документы как можно быстрее (скан), ерунда выходит. Все ровно только в одном случае, когда мы работаем с компанией в системе электронного документооборота. А в остальных - человеческий фактор, когда иногда ошибку в документах приходится неделями выяснять.

Дебиторка по первичке - это гемморой всех видов бизнеса. Сейчас некоторые покупатели идут другим путем: сначала весь пакет документов, потом только товар и только потом оплата. Хотя и этот путь не избавляет от проблем, т.к. приход товара и первичный документ - не всегда совпадают :))
Запрет изменений задним числом не прокатывает больше из-за нашего дурного законодательства, чем из-за человеческого фактора. Люди везде совершают ошибки.
Сейчас практика такая, что по ролям настраивают количество дней, в течении которого можно вносить изменения в документы. Кроме документов есть еще справочники, за изменениями в которых надо следить...
26.01.2017 07:14
OlegON
 
Цитата:
FinSoft на производительность системы влияние не принципиальное
Еще раз подчеркну, на маленьких системах непринципиальная. Если больше 100 человек сидят, что-то меняют в базе больше 100Гб, то чувствоваться будет очень хорошо. И как админы вымаливают диски не для производительности, а лишь бы только влезло, я тоже свидетель неоднократно.
26.01.2017 09:33
Nitro Junkie
 
Цитата:
OlegON Еще раз подчеркну, на маленьких системах непринципиальная. Если больше 100 человек сидят, что-то меняют в базе больше 100Гб, то чувствоваться будет очень хорошо. И как админы вымаливают диски не для производительности, а лишь бы только влезло, я тоже свидетель неоднократно.
Ну это странный аргумент, у нас каждое изменение строки логируется, в том числе количества и цен (а у многих клиентов количество одновременных пользователей существенно больше 100). Более того пользователь (с правами соответствующими естественно) может включить логирование изменение любого (!), в том числе вычисляемого (!), показателя который он видит, и они этим активно пользуются. И никакой особенной проблемы с местом не замечали. Все равно те же чеки жрут значительно больше места чем вся остальная база (даже с логами). Для этого просто создается tablespace отдельный на hdd и туда скидываются редко используемые данные (логи чеки и т.п.). При этом сейчас даже в любом ноуте больше террабайта hdd диск.
26.01.2017 10:01
OlegON
 
Ничего странного. Давайте от теории ближе к практике, допустим, средняя накладная из 5000 строк, сохранение деталей по каждой строке с накладными, ну, пусть 1Кб, это немного, учитывая накладные расходы, в т.ч. на индексы. Итого, 5Мб на изменение накладной. 100 человек могут выдать до 100 измененных накладных в минуту, т.е. до 500Мб в минуту прироста и записи на диск. А теперь представим, что в ЦО стекаются данные со всех магазинов и кто-то проводит инвентаризацию с простановкой цен... Очень даже круто растет база... А это еще рост и ее бекапа, т.е. диски только подносить надо будет...
26.01.2017 10:45
Nitro Junkie
 
Цитата:
OlegON Ничего странного. Давайте от теории ближе к практике, допустим, средняя накладная из 5000 строк, сохранение деталей по каждой строке с накладными, ну, пусть 1Кб, это немного, учитывая накладные расходы, в т.ч. на индексы. Итого, 5Мб на изменение накладной. 100 человек могут выдать до 100 измененных накладных в минуту, т.е. до 500Мб в минуту прироста и записи на диск. А теперь представим, что в ЦО стекаются данные со всех магазинов и кто-то проводит инвентаризацию с простановкой цен... Очень даже круто растет база... А это еще рост и ее бекапа, т.е. диски только подносить надо будет...
Не совсем понял почему лог должен занимать больше самих данных. То есть размер лога = размер данных + размер данных * коэффициент правок (лога). Коэффициент правок хорошо если 10%. Итого размер базы увеличивается в 2.1 раза. При этом если взять чеки которые нет смысла логировать, то даже в системе класса ЕРП все остальные данные с логированием будут все равно в раза 2 меньше размера таблиц чеков. Итого общий размер с логами увеличится процентов на 20. А если учесть что логи и чеки можно положить на hdd то проблема размера логов по-любому надумана.
26.01.2017 10:54
FinSoft
 
Цитата:
OlegON Еще раз подчеркну, на маленьких системах непринципиальная. Если больше 100 человек сидят, что-то меняют в базе больше 100Гб, то чувствоваться будет очень хорошо. И как админы вымаливают диски не для производительности, а лишь бы только влезло, я тоже свидетель неоднократно.
Олег, рабочая часть лога обычно содержит только дневные изменения. Остальное в архивах. Считай, что они за пределами базы данных. Опять таки, мы понимаем, что логировать есть смысл только те данные, которые изменяются. В частности, в сетевой рознице львиная часть данных - это чеки, пробиваемые на кассах. Их логировать смысла нет, так как они не изменяются.
Логирование, конечно, требует дополнительные вычислительные ресурсы. Но производительность работы в гораздо большей степени зависит от структуры базы данных и методик работы с ней.


Опции темы


Часовой пояс GMT +3, время: 02:16.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.