Сопровождение MBS

[ALEG]

Цитата:

Сообщение от Bobkov

Привет!

Я думаю, что стратегически очень важно поставить методическую работу. Цель этой работы - стандартизация и унификация способов автоматизации конкретных бизнес-процессов клиента с помощью конкретных продуктов MS, для того чтобы внедренец этого продукта, встретившись с новым для него бизнес-процессом, не лепил второпях отсебятину, а мог воспользоваться чужим опытом.
Для этого можно например издавать журнал типа "Best Practice" по внедрению. .

Очень верно отмечено. Работа в этом направлении ведется. Сейчас партнерам досутпен Rapid Configuration Tool (бывший ERP Complete). Пока только на английском языке
http://www.microsoft.com/BusinessSol...tion_tool.mspx
Но это больше касается внедрения. Касательно сопровождения очень хочется обсудить реальные технические проблемы upgrade. Т.е. что лучше "выкусывать" требуемые наработки из последнего FP или поднимать свои на последний SP или FP.
В данном конкретном вопросе очень нужно мнение профессионалов. Мы можем теоритически напридумывать что угодно, но без вашего мнения это может так и остаться теорией.

[EVGL]

Цитата:

Сообщение от ALEG

Касательно сопровождения очень хочется обсудить реальные технические проблемы upgrade.

Вот вам конструктив из-за рубежа, реальные технические проблемы upgrade за пределами бывшего СССР:

• венгр не ожидает, что при инсталляции "России" помимо обычных ald-файлов будут изменены font substitutes. Сделайте российские шрифты отдельным пунктом в инсталляторе;
• задокументируйте конфигурационные ключи *_W: напишите попросту справа от каждого, для каких стран Восточной Европы он должен быть активирован; то же самое для кассы, ведь даже не все польские партнеры знают, что русская касса теперь работает и для Польши;
• сделайте поля, в которых сохраняются налоги по строке для invoice, не только чисто российскими, а общими для Восточной Европы;
• сделайте также "Генератор Российской Отчетности" общим для Восточной Европы;
• напишите на этом форуме, что вы видели это сообщение и будете реагировать; в противном случае больше никакого конструктива не будет.

[mazzy]

Цитата:

Сообщение от EVGL

в противном случае больше никакого конструктива не будет.

Конструктива не будет от кого?
Надеюсь, ты не собираетешься уничтожать форум, чтобы ВООБЩЕ не было конструктива?
Спрашиваю совершенно серьезно - не понимаю я шуток относительно форума.

[komar]

Цитата:

Сообщение от EVGL

Вот вам конструктив из-за рубежа, реальные технические проблемы upgrade за пределами бывшего СССР:

• венгр не ожидает, что при инсталляции "России" помимо обычных ald-файлов будут изменены font substitutes. Сделайте российские шрифты отдельным пунктом в инсталляторе;
• задокументируйте конфигурационные ключи *_W: напишите попросту справа от каждого, для каких стран Восточной Европы он должен быть активирован; то же самое для кассы, ведь даже не все польские партнеры знают, что русская касса теперь работает и для Польши;
• сделайте поля, в которых сохраняются налоги по строке для invoice, не только чисто российскими, а общими для Восточной Европы;
• сделайте также "Генератор Российской Отчетности" общим для Восточной Европы;

Как говорится, нам бы ваши проблемы...

[kvan]

Цитата:

Сообщение от ALEG

Касательно сопровождения очень хочется обсудить реальные технические проблемы upgrade. Т.е. что лучше "выкусывать" требуемые наработки из последнего FP или поднимать свои на последний SP или FP

Сделайте оба варианта. Только очень бы хотелось чтоб результат установки обоих был одинаковым.

[ALEG]

Цитата:

Сообщение от kvan

Сделайте оба варианта. Только очень бы хотелось чтоб результат установки обоих был одинаковым.

Тут возникает следующая проблема. Сервис пак = пакет исправления для найденых и исправленных ошибок + улучшения производительности и т.д. Новые разработки выполняются на последней версии. Т.е. например SP4 + 60 исправленных ошибок или просто доработок. Для того, чтобы выпустить модификацию по НДС как новый SP или FP + отдельным хотфиксом к SP3 например, то надо сделать и протестировать на SP4 + баги и потом опустить на SP3. В любом случае делать 2 раза. В некоторых случаях это не сложно, в некоторых придется помимо основной модификации опускать кучу другого функционала.
Это тупиковая ветка развития. Кто несогласен, аргументы в студию.

Мое личное мнение, что исправление для критических проблем могут быть установлены в индивидуальном порядке, так как последствия дороже. Исправления прочих незначительных ошибок должны проводиться регламентно 1 раз в квартал (месяц) и тестироваться.

Для кого-нибудь знакома ситуация когда пользователи приходят утром на работу и начинаю искать того, кто ночью вносил какие-то исправления? Они уже не удивляются, а просто ищут того, кто что-то в системе изменял.

[kvan]

Цитата:

Сообщение от ALEG

+ улучшения производительности и т.д.

Цитата:

Сообщение от ALEG

Новые разработки выполняются на последней версии. Т.е. например SP4 + 60 исправленных ошибок или просто доработок. Для того, чтобы выпустить модификацию по НДС как новый SP или FP + отдельным хотфиксом к SP3 например, то надо сделать и протестировать на SP4 + баги и потом опустить на SP3. В любом случае делать 2 раза. ... Это тупиковая ветка развития. Кто несогласен, аргументы в студию.

Да не надо мне для SP3 или древнего SP1. Допустим что у меня есть приложение (много своего функционала) поднятое до SP4. Вышел ваш FP1 - так какого же овоща не выпустить его в виде проекта!? Я не могу поднимать такой обьем кода на новую версию по любому вашему чиху! ДАЙТЕ МНЕ ВОЗМОЖНОСТЬ выбирать что поднимать - мой код или ваш!
Хорошо бы было получать новый SP в виде проекта для наката на предыдущий - но требовать от вас это бессмысленно ... слишком сложно это для вас Я уж без вас решил бы - вливать мне несколько проектов(SP + FP + какой нить HF) или поставить готовое приложение и "бороться" со своим "творчеством".
Хоть заплатки не выпускайте толкьо в виде нового приложения ...

Цитата:

Сообщение от ALEG

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

А вы свое мнение на практике пробывали применять?
Прочитайте еще раз пост от Lazy_Tiger и обратите внимание сколько дней партнер планирует потратить на подьем его приложения на вашу заплатку для критической проблемы!

Цитата:

Сообщение от ALEG

Для кого-нибудь знакома ситуация когда пользователи приходят утром на работу и начинаю искать того, кто ночью вносил какие-то исправления? Они уже не удивляются, а просто ищут того, кто что-то в системе изменял.

Причем здесь это!? Это проблема клиента если он не может организовать свою команду. Какое это отношение имеет к новым версиям?

[Lazy_Tiger]

Цитата:

Сообщение от ALEG

+ улучшения производительности и т.д.

Улыбнули, ей богу. Я щас не буду вспомнинать про закрытие склада, тема приелась. Я щас вспомню про "обработку входящего НДС". Знаете сколько оно хотело за месяц считать это дело? Ответ - 44 часа (не факт что посчитало бы, на вторые сутки пришлось сесть и подумать). А знаете за сколько считает сейчас? За 40 минут-час. Это разница возникла изза перестройки 2х (двух) индексов и переписывания 10 строк кода. Это к вопросу о том как пишут Ваши программисты и как те, кого пользователи пинают. Очень хочется вспомнить про производительность 1С и громкие заявления о том что аксапта производительнее во много раз. Но не буду.

Цитата:

Сообщение от ALEG

Мое личное мнение, что исправление для критических проблем могут быть установлены в индивидуальном порядке, так как последствия дороже. Исправления прочих незначительных ошибок должны проводиться регламентно 1 раз в квартал (месяц) и тестироваться.

Исправления для "критических" проблем (я опять про склад) могут быть установлены на систему оперативно только при условии наличия документации на проблему и тщательно задокументированного проекта (.xpo). Для всех существующих на сегодняшний день и поддерживаемых SP. Иначе их установка будет являться отдельным проектом с весьма и весьма нехилым бюджетом.

С исправление "незначительных" ошибок (а можно Я буду определять что для меня незначительно? пожалуйста) мы как нить уж сами справимся, в оперативном режиме.

[mazzy]

Цитата:

Сообщение от Lazy_Tiger

Это разница возникла изза перестройки 2х (двух) индексов и переписывания 10 строк кода. Это к вопросу о том как пишут Ваши программисты и как те, кого пользователи пинают. Очень хочется вспомнить про производительность 1С и громкие заявления о том что аксапта производительнее во много раз. Но не буду.

А зря. Попробовал бы ты в 1С найти эти два чудесных индекса и 10 строк кода... что давали бы прирост на порядки
Там производительность поднимается на десятки процентов за счет тотального переписывания конфигурации.

Впрочем, это ОФФ. И этот ОФФ нисколько не отменяет необходимость работ вендора над производительностью.

[komar]

Цитата:

Сообщение от mazzy

А зря. Попробовал бы ты в 1С найти эти два чудесных индекса и 10 строк кода... что давали бы прирост на порядки

Хороший подход! Напоминает анекдот с рецептом для счастья "купи козу - прогони козу". Если система работает медленно - нужно отрехтовать пару строк кода, чтобы потом это "медленно" раем показалось!

[Alexius]

Цитата:

Сообщение от mazzy

Попробовал бы ты в 1С найти эти два чудесных индекса и 10 строк кода... что давали бы прирост на порядки
Там производительность поднимается на десятки процентов за счет тотального переписывания конфигурации.

что-ж поставим 1С жирный плюсик за гораздо более полное и грамотное использование возможностей своей платформы

[Lazy_Tiger]

Цитата:

Сообщение от mazzy

А зря. Попробовал бы ты в 1С найти эти два чудесных индекса и 10 строк кода... что давали бы прирост на порядки
Там производительность поднимается на десятки процентов за счет тотального переписывания конфигурации.

а вот не припомню я чтобы на инсталяциях 1С кто-то вообще занимался индексами, раскидыванием таблиц по дискам и т.д. Могу поинтересоваться в Сервисном центре Русала, одна из крупнейших известных мне инсталяций 1С, но как то в разговорах ничо ТАКОГО не всплывало ни разу. Переписывание конфы - да. А вот борьба с индексами - не слышал ни разу.

P.S. Если я скажу на какую СУБД щас там 1С переводят и на каком железе... УУУУ. никто не поверит

[Nick]

Цитата:

Сообщение от Lazy_Tiger

а... А вот борьба с индексами - не слышал ни разу.

У 1С:Предприятия 7.7 в dbf-варианте вечная проблема с индексами, особенно когда кол-во одновременно активно работающих пользователей больше пяти

[George Nordic]

Цитата:

Сообщение от Lazy_Tiger

P.S. Если я скажу на какую СУБД щас там 1С переводят и на каком железе... УУУУ. никто не поверит

Подождем 23го. Думаю, там как раз об этом и скажут

С Уважением,
Георгий

[mazzy]

Цитата:

Сообщение от Lazy_Tiger

Для всех существующих на сегодняшний день и поддерживаемых SP.

Угу. Я же говорил!
Как накатывать сервис-паки: нужен ли xpo?

[Lazy_Tiger]

Цитата:

Сообщение от mazzy

Угу. Я же говорил!
Как накатывать сервис-паки: нужен ли xpo?

Так ведь и речь про исправление КРИТИЧЕСКИХ ошибок
Не "хотелки" даже, не новый функционал, а КРИТИЧЕСКИЕ ошибки.

Еще разик и это мое мнение.
1) Определять критическая это ошибка или нет, должен клиент, а не некто в Дании, причем с этим некто я даже теоретически списаться не могу, потому что он и по русски то не бельмеса.
2) Оплачивать исправление ошибок проектирования и реализации кода, написанного поставщиком, должен сам поставщик. Это проблемы МБС и их затраты.

И пока я аргументов кроме "это сложно и дорого для нас" от поставщика не услышал. А такое объяснение не очень устраивает, потому что если поставщик на этом экономит, то это становится сложно и дорого уже для меня, а ресурсы несопоставимы. Суммы только за 1 (один) месяц, потребные для того чтобы провернуть эти работы силами партнера я уже обозначал.

Кстати, ничего плохого про партнера своего сказать не могу, люди реально помогают разобраться в проблеме и пытаются ее решить. И решают. Без помощи, а скорее даже вопреки "усилиям" МБС

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

P.P.S. Когда там у нас клуб клиентов? Топ-менеджмент западный будет? Хочу в глаза бестыжие посмотреть...

[ALEG]

Цитата:

Сообщение от Lazy_Tiger

P.P.S. Когда там у нас клуб клиентов? Топ-менеджмент западный будет? Хочу в глаза бестыжие посмотреть...

Предлагаю не в глаза бестыжие смотреть, а сесть и поговорить. Со мной можно 3 февраля например в Дятле. Можно позвонить, написать.

[ALEG]

Цитата:

Сообщение от Lazy_Tiger

Знаете сколько оно хотело за месяц считать это дело? Ответ - 44 часа (не факт что посчитало бы, на вторые сутки пришлось сесть и подумать). А знаете за сколько считает сейчас? За 40 минут-час. Это разница возникла изза перестройки 2х (двух) индексов и переписывания 10 строк кода.

А можно в студию эти чудо 10 строк кода и 2 индекса?
Можно в новостной группе занести новый post и посмотреть какие будут ответы разработчиков.

[ALES]

Цитата:

Сообщение от ALEG

А можно в студию эти чудо 10 строк кода и 2 индекса?

Приснилось мне письмо "партнеры, напишите, были ли проблемы с производительностью версии 2.5 и как реш(а)или" и ответ PMа - "очень просто -через суд".
Понятно, что и индексы и 10 строчек, у каждого клиента скорей всего свои, но почему-то Леша, до сих пор не очень верится, что тестирование "sys" ... "dis" функциональности, ведется на объемах данных, хоть как-то приближенных к "боевым"

[Ax1D]

Цитата:

Сообщение от ALES

Понятно, что и индексы и 10 строчек, у каждого клиента скорей всего свои, но почему-то Леша, до сих пор не очень верится, что тестирование "sys" ... "dis" функциональности, ведется на объемах данных, хоть как-то приближенных к "боевым"

Не могу сказать про sys и dis, но последний Kernel Rollup 1 к Ахапте 3 тестировался в том числе и на реальных данных (объёмом 50К saleslines в день) у нас на проекте. И приезжали специалисты из MBS для разрешения проблем с производительностью тоже не раз. Может внедрение какое-то особенное, не могу сказать.