Показано с 181 по 210 из 373
-
31.05.2011, 00:22 #181
- Регистрация
- 25.11.2005
- Сообщений
- 2,723
Наверное надо было предупредить. Имеет место реально работающая система с нехилым функционалом на предприятии в 7500 человек (в т.ч. 70 служба IT, в т.ч. сильные программеры). И это не понты ЕРП внедряльников, а полновесный спрут, без которого уже давно никто ни шагу. Изменения тоже работают, но некрасиво, трудозатратно и с нарушениями правил (например, могут в обход процедуры изменить заявку, на которую есть договор).
Я думаю, задачу будем решать так. Цех-заказчик создает в отдельном приложении заголовок (номер, дата) заявки на изменение своей сводной заявки и ее спецификацию. Приложение блокирует нарушение правил и выгружает выбранное в шаблон Экселевого файла. В Экселе заказчик проводит моделирование, пытаясь скомпенсировать изменение через "Удалить-Изменить" ("Добавить" было сделано в Парусе и скинуто приложением в Эксель). Когда все закончено, заказчик экспортирует (транзакция) Эксель в приложение, причем если он перемудрил, экспорт не пройдет (а не надо быть таким хитро*опым). Далее из приложения он получает распечатку Заявки на изменение, защищенную от подделки. Бумагу согласовывают и утверждают, затем приложением "проводят" по Парусу.
Искомый Эксель хранится, как реплика и при этом входит в текущую версию БД (которая "стало") Парус; все предыдущие версии ("было") хранятся отдельно. Решение о сохранении новой версии и присвоении ей нового номера принимает тот, кто отвечает за взаимодействие с Центром. Он же в настройках отчета "было-стало" и указывает, какую версию принимать за "было". То есть, в двух БД достаточно первички, так что изменение или пересмотр-задача на интерфейс. Как то так.Последний раз редактировалось Михаил_Шустер; 31.05.2011 в 00:50.
-
31.05.2011, 01:26 #182
- Регистрация
- 25.11.2005
- Сообщений
- 690
Сообщение от Михаил_Шустер
Сообщение от Михаил_Шустер
Сообщение от Михаил_Шустер
Вощем у тебя дерево, один терминальный узел которого является "стало".
И если терминальных узлов > 1 то должна быть правило выбора - или выбрать последнее "стало" или любой узел начиная от корня по какому то критерию.
-
31.05.2011, 09:39 #183
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Михалыч, может быть мнение о крутости ваших программистов слегка э ... субъективное?
Вообще-то такие задачки они должны щелкать как семечки, причем средствами Паруса ... Хотя я не знаю какая у вас пыхтит версия этого динозавера - если совсем юрского периода, то могут быть проблемы с внутренними доработками.
Насколько я понял твою задачу, это что-то типа:
1. Сбор заявок на закупки.
2. Консолидация заявок в ГКПЗ (годовую комплексную программу закупок) и ее утверждение как документ.
3. Внесение изменений в заявку и/или новых заявок.
- Регистрация запроса на изменение.
- Проверка влияния на другие заявки и консолидированные итоги ГКПЗ.
- Согласование запроса (принять-отклонить-заморозить).
4. Завершение операционного дня: Оценка общего отклонения по ГКПЗ (плюс-минус 10% или сколько у вас там), если превышает - утверждение новой версии ГКПЗ. Старые сохраняются с возможностью отката.
Как видишь, ничего мега-сложного. Нужно только кое-что поменять в консерватории (построить закупщиков), ну и договориться с программистами чтобы они автоматизировали не то что им хочется, а то что необходимо.
-
31.05.2011, 12:05 #184
- Регистрация
- 25.11.2005
- Сообщений
- 2,723
Сообщение от Сахават
А как узнать - мышью ткнуть, как еще? Или ты насчет "допустимо ли?" - тут никакого искусственного интеллекта. Человек отвечает-человек тыкает. Мы нашли остроумную замену нормативам и не вернемся к ним, ты об этом? Заявки делятся на постоянные и разовые. Постоянные - тематические, хорошо структурированы, это очень похоже на нормативы, но мягче. А от ошибок страхует наглядность.
Сообщение от Сахават
Сообщение от Сахават
Сообщение от Сахават
Это нормально. Незачем автоматизировать лишнееПоследний раз редактировалось Михаил_Шустер; 31.05.2011 в 12:24.
-
31.05.2011, 13:39 #185
- Регистрация
- 25.11.2005
- Сообщений
- 2,723
Пришли программеры и все испортили. Приложение будут в Парусе писать, без Экселя
Концептуально все так же, но лучше: есть две копии записи: до и после изменения
-
31.05.2011, 14:18 #186
- Регистрация
- 25.11.2005
- Сообщений
- 2,723
Типа кейс
Форум последнее время скучноват, предлагаю типа кейс для оживлежу.
Чисто кому интересно. Ну... как кроссворд, где все ответы, как у Шекли, правильные и неправильные одновременно.
Предложения-замечания-жалобы-рассуждения-обобщения-КГАМ... в принципе показан срез существенной части системы управления через подсистему ее изменений.
ЗЫ. Обвинения типо "хочете мудрость забесплатно" с негодованием отметаю.
-
31.05.2011, 14:58 #187
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Сообщение от Михаил_Шустер
Предлагаю описать через диаграммы ЖЦ заявки на изменение, совокупной годовой заявки.
Здесь, по-моему, самое главное, это алгоритм принятия/непринятия заявки полуавтоматизированно (укладывается - принимаем, нет - не принимаем), и приоритеты должен назначать утверждающий (утверждающие).
-
31.05.2011, 15:49 #188
- Регистрация
- 25.11.2005
- Сообщений
- 2,723
Сообщение от Andruxa
Сообщение от Andruxa
Удобна для презентаций, позже покажу почему
Сообщение от Andruxa
-
31.05.2011, 16:13 #189
- Регистрация
- 10.07.2009
- Сообщений
- 240
Сообщение от Михаил_Шустер
Ого-го, у вас Ген дир прямо мегамозг какой-то. По ЗИ-02 как-то совсем непросто сформировать базу для окончательного суждения при принятии решения об утверждении.
Вы кстати ЗИ-06 забыли добавить.Последний раз редактировалось folio; 31.05.2011 в 16:21.
-
31.05.2011, 16:33 #190
- Регистрация
- 25.11.2005
- Сообщений
- 2,723
Сообщение от folio
Второй (ЖЦ) - это собственно процесс, который должен быть обслужен системой изменений. Если комент к нему - вроде все нормально: директор только разруливает вопросы, которые РН (руководители направлений) не смогли решить своей властью. Это делается на совещаниях. Если (когда) вопросов нет, директор подписывает талмуд, глядя только на первый лист (агрегаты)
На изменениях-аналогично. Если заявка скомпенсирована (по статье не произошло удорожания) и руководители направлений подписали-утверждает не разбираясь. Предлагал ему оставить за собой утверждение только проблемных изменений - не хочет пока, его дело.
-
31.05.2011, 16:52 #191
- Регистрация
- 10.07.2009
- Сообщений
- 240
Я про п 3.3 и 3.4 положения и приложение б (т.е. первый файл).
-
31.05.2011, 16:58 #192
- Регистрация
- 25.11.2005
- Сообщений
- 2,723
Сообщение от folio
-
31.05.2011, 18:56 #193
- Регистрация
- 25.11.2005
- Сообщений
- 2,723
Изменения заявки в виде мультика для обучения (фрагмент)
(заодно диагностика, лечение и самопроверка)
-
31.05.2011, 19:20 #194
- Регистрация
- 25.11.2005
- Сообщений
- 2,723
Когда занимался аудитом, все пытался выдумать форму отчета, чтоб наглядно донести проблемы и способы их устранения. Находил обычно много, но в таблице находки смазывались, часть выносил в общие положения, но ни на чем толком не остановился.
Мультик мне нравится больше всего. Пока. На примере он весь в звездочку-такова ситуация, но возможны варианты - вот другой пример, без подробностей
-
31.05.2011, 19:21 #195
- Регистрация
- 25.11.2005
- Сообщений
- 2,723
Забыл на всякий случай сказать
Перед просмотром давите F5
-
31.05.2011, 23:15 #196
- Регистрация
- 10.07.2009
- Сообщений
- 240
Сообщение от Михаил_Шустер
-
31.05.2011, 23:55 #197
- Регистрация
- 25.11.2005
- Сообщений
- 2,723
Сообщение от folio
Ну а если не повезло-тут ничего не поможет
Сообщение от folio
Чтоб не нивелировалось, система изменений должна быть надежной
Создать первую версию СГЗ не слишком сложно. А вот не дать ей расползтись-в разы сложнее, это как динамика супротив статики. Но любой план или бюджет без системы изменений - досужая игрушка (см неопределенность планирования)
-
01.06.2011, 00:26 #198
- Регистрация
- 10.07.2009
- Сообщений
- 240
Сообщение от Михаил_Шустер
По ЗИ-02 как-то совсем непросто сформировать базу (предпосылок) для окончательного суждения при принятии решения об утверждении.
Сообщение от Михаил_Шустер
З.Ы. Я, честно говоря, просто, наверно недопониманию, почему заветная плюшка (изменение) достаётся так просто.Последний раз редактировалось folio; 01.06.2011 в 12:52.
-
01.06.2011, 11:22 #199
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Сообщение от Михаил_Шустер
-
01.06.2011, 13:30 #200
- Регистрация
- 25.11.2005
- Сообщений
- 690
Сообщение от Andruxa
заявка - 100 молотков
ответ - блин , у тебя же всего три дачи!?
-
01.06.2011, 13:31 #201
- Регистрация
- 25.11.2005
- Сообщений
- 2,723
Сообщение от Andruxa
Слева руководители, ответственные за направления
Под руководителями - подразделения, распоряжающиеся лимитами от их имени
Заказчики скрыты в агрегатах, там свои отчеты и ОЛАПы
Цифры и прочие подробности вытерты из-за товарища майора
-
01.06.2011, 13:36 #202
- Регистрация
- 25.11.2005
- Сообщений
- 2,723
Сообщение от Сахават
Лимиты - это и есть бюджет на нормальном языке. А заявки - это конкретные товары и услуги, на которые и заказано\разрешено израсходовать бюджет
Бюджетный пилинг - это когда все бабло пилят по людям, те - по другим людям, а те еще дальше и так до конца. Наукообразно звучит иначе, но смысл тот же повсеместно
-
01.06.2011, 13:57 #203
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Сообщение от Сахават
-
01.06.2011, 13:58 #204
- Регистрация
- 25.11.2005
- Сообщений
- 2,723
Сообщение от folio
При отсутствии таковых, до директора доходит сформулированная проблема.
Сообщение от folio
Я не сторонник жестких планов, столь модных в государевой собственности. Они никогда не выполняются, с чем связано 90% государева геморроя. Важен баланс: слишком гибкий план - ручное управление, слишком жесткий - перерасход средств на глупости. Среди годовых планировщиков нет провидцев, это почему-то не все понимают.
Для постоянных и разовых заявок разная неопределенность, в этом направлении работа тоже ведется, про нее как нибудь потом.
-
01.06.2011, 14:58 #205
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от Andruxa
Сообщение от Andruxa
-
01.06.2011, 15:27 #206
- Регистрация
- 10.07.2009
- Сообщений
- 240
Сообщение от Михаил_Шустер
У меня глупейший вопрос: а насколько необходимо такое частое перебалансирование?
Ведь у этого подхода есть обратная сторона, которую вы зафиксировали в мультике: от утяжеления самой системы, до учёта и использования изменений.
-
01.06.2011, 15:55 #207
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от Михаил_Шустер
Ты даже сам где-то тут писал, что есть группы позиций по оборудованию которые повторяются из года в год и могут планироваться с точностью 99%. У нас так же.
-
01.06.2011, 16:04 #208
- Регистрация
- 25.11.2005
- Сообщений
- 2,723
Сообщение от folio
Тема "неопределенность", "горизонт планирования", набегающая волна, зпарос на изменение и т.п. много рассмотрена в РМВОКе и я практически со всем этим согласен. Про управление неопределенностями и соответствующие риски в форуме года 3 назад обсуждалось
Однако, основная позиция - за каждым проектом (направлением, лимитом) должен стоять конкретный смотрящий ФИО. Который и обязан установить надлежащий порядок в том числе - по вопросу перебалансирования.
А у ФИО на плече должна быть рука друга. Одна. Потому что вторая занята.
Пистолетом
-
01.06.2011, 17:57 #209
- Регистрация
- 24.09.2009
- Сообщений
- 318
Я не осилил последние 3 или 4 страницы повалившего флуда, просто дам две достаточно серьезные ссылки, которые позволят понять разницу между управлением изменениями (change management) и управлением интеграцией проекта (integration management):
http://businesslearning.ru/CoursFrm.asp?actid=175
http://www.intuit.ru/department/itmngt/changemanage/1/
-
02.06.2011, 00:25 #210
- Регистрация
- 25.11.2005
- Сообщений
- 2,723
Сообщение от Михайло