Управление проектами и управление изменениями

[Михаил_Шустер]

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

Я думаю, задачу будем решать так. Цех-заказчик создает в отдельном приложении заголовок (номер, дата) заявки на изменение своей сводной заявки и ее спецификацию. Приложение блокирует нарушение правил и выгружает выбранное в шаблон Экселевого файла. В Экселе заказчик проводит моделирование, пытаясь скомпенсировать изменение через "Удалить-Изменить" ("Добавить" было сделано в Парусе и скинуто приложением в Эксель). Когда все закончено, заказчик экспортирует (транзакция) Эксель в приложение, причем если он перемудрил, экспорт не пройдет (а не надо быть таким хитро*опым). Далее из приложения он получает распечатку Заявки на изменение, защищенную от подделки. Бумагу согласовывают и утверждают, затем приложением "проводят" по Парусу.

Искомый Эксель хранится, как реплика и при этом входит в текущую версию БД (которая "стало") Парус; все предыдущие версии ("было") хранятся отдельно. Решение о сохранении новой версии и присвоении ей нового номера принимает тот, кто отвечает за взаимодействие с Центром. Он же в настройках отчета "было-стало" и указывает, какую версию принимать за "было". То есть, в двух БД достаточно первички, так что изменение или пересмотр-задача на интерфейс. Как то так.

[Сахават]

Я думаю, задачу будем решать так. Цех-заказчик создает в отдельном приложении заголовок (номер, дата) заявки на изменение своей сводной заявки и ее спецификацию. Приложение блокирует нарушение правил и выгружает выбранное в шаблон Экселевого файла.

Как узнать что выбрать?

В Экселе заказчик проводит моделирование, пытаясь скомпенсировать изменение через "Удалить-Изменить" ("Добавить" было сделано в Парусе и скинуто приложением в Эксель).

В какую версию добавили?

Он же в настройках отчета "было-стало" и указывает, какую версию принимать за "было"

а куда добавили, если не знали что "было"?

Вощем у тебя дерево, один терминальный узел которого является "стало".
И если терминальных узлов > 1 то должна быть правило выбора - или выбрать последнее "стало" или любой узел начиная от корня по какому то критерию.

[А.Б.]

Михалыч, может быть мнение о крутости ваших программистов слегка э ... субъективное?
Вообще-то такие задачки они должны щелкать как семечки, причем средствами Паруса ... Хотя я не знаю какая у вас пыхтит версия этого динозавера - если совсем юрского периода, то могут быть проблемы с внутренними доработками.

Насколько я понял твою задачу, это что-то типа:
1. Сбор заявок на закупки.
2. Консолидация заявок в ГКПЗ (годовую комплексную программу закупок) и ее утверждение как документ.
3. Внесение изменений в заявку и/или новых заявок.
- Регистрация запроса на изменение.
- Проверка влияния на другие заявки и консолидированные итоги ГКПЗ.
- Согласование запроса (принять-отклонить-заморозить).
4. Завершение операционного дня: Оценка общего отклонения по ГКПЗ (плюс-минус 10% или сколько у вас там), если превышает - утверждение новой версии ГКПЗ. Старые сохраняются с возможностью отката.

Как видишь, ничего мега-сложного. Нужно только кое-что поменять в консерватории (построить закупщиков), ну и договориться с программистами чтобы они автоматизировали не то что им хочется, а то что необходимо.

[Михаил_Шустер]

Как узнать что выбрать?

Как узнал? У нас тут действительно затруднение Но это рабочий момент
А как узнать - мышью ткнуть, как еще? Или ты насчет "допустимо ли?" - тут никакого искусственного интеллекта. Человек отвечает-человек тыкает. Мы нашли остроумную замену нормативам и не вернемся к ним, ты об этом? Заявки делятся на постоянные и разовые. Постоянные - тематические, хорошо структурированы, это очень похоже на нормативы, но мягче. А от ошибок страхует наглядность.

В какую версию добавили?

Это еще не версия, а таблица для моделирования. Становится репликой после того, как из нее сделан экспорт. Хранится в БД приложения. Вопрос версионности решается не здесь, а в Парусе, когда из имеющихся данных на выбранную дату и повод, делается официальный срез, который и становится "было"

а куда добавили, если не знали что "было"?

Ночью, вместо чтоб спать, додумал: в модельной таблице должны быть две колонки количества, было и стало. Корректировать можно только последнюю.

должна быть правило выбора

Правило простое: кто отвечает, тот и выбирает.
Это нормально. Незачем автоматизировать лишнее

[Михаил_Шустер]

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

[Михаил_Шустер]

Форум последнее время скучноват, предлагаю типа кейс для оживлежу.
Чисто кому интересно. Ну... как кроссворд, где все ответы, как у Шекли, правильные и неправильные одновременно.
Предложения-замечания-жалобы-рассуждения-обобщения-КГАМ... в принципе показан срез существенной части системы управления через подсистему ее изменений.
ЗЫ. Обвинения типо "хочете мудрость забесплатно" с негодованием отметаю.

[Andruxa]

Предложения-замечания-жалобы-рассуждения-обобщения-КГАМ...

Сложновато-абстрактновато.
Предлагаю описать через диаграммы ЖЦ заявки на изменение, совокупной годовой заявки.

Здесь, по-моему, самое главное, это алгоритм принятия/непринятия заявки полуавтоматизированно (укладывается - принимаем, нет - не принимаем), и приоритеты должен назначать утверждающий (утверждающие).

[Михаил_Шустер]

Сложновато-абстрактновато

Просто слишком много деталей за кадром.

Предлагаю описать через диаграммы ЖЦ

ЖЦ заявки, как предмета изменений в произвольной нотации
Удобна для презентаций, позже покажу почему

главное, это алгоритм принятия/непринятия заявки полуавтоматизированно

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

[folio]

Просто слишком много деталей за кадром.

Комент, просто комент:
Ого-го, у вас Ген дир прямо мегамозг какой-то. По ЗИ-02 как-то совсем непросто сформировать базу для окончательного суждения при принятии решения об утверждении.

Вы кстати ЗИ-06 забыли добавить.

[Михаил_Шустер]

у вас Ген дир прямо мегамозг какой-то

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

[folio]

Я про п 3.3 и 3.4 положения и приложение б (т.е. первый файл).

[Михаил_Шустер]

Я про п 3.3 и 3.4 положения и приложение б (т.е. первый файл).

Обычный порядок. Директор смотрит общую цифру небаланса и наличие подписей. Если ОК-подписывает, если нет-его дело: подписать, отказать, позвонить, вызвать, написать резолюцию

[Михаил_Шустер]

Изменения заявки в виде мультика для обучения (фрагмент)
(заодно диагностика, лечение и самопроверка)

[Михаил_Шустер]

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

[Михаил_Шустер]

Забыл на всякий случай сказать
Перед просмотром давите F5

[folio]

Обычный порядок. Директор смотрит общую цифру небаланса и наличие подписей. Если ОК-подписывает, если нет-его дело: подписать, отказать, позвонить, вызвать, написать резолюцию

По ощущениям - это слабое звено (одно из). Смысл ЖЦ нивелируется возможностью внесения изменений.

[Михаил_Шустер]

По ощущениям - это слабое звено

Директор-нормальный пробой в системе. Можно прийти к нему и получить подпись в обход всех процедур. В принципе, это его работа, делать исключения из правил. Защита одна: дураки среди директоров редкость.
Ну а если не повезло-тут ничего не поможет

Смысл ЖЦ нивелируется возможностью внесения изменений.

???
Чтоб не нивелировалось, система изменений должна быть надежной
Создать первую версию СГЗ не слишком сложно. А вот не дать ей расползтись-в разы сложнее, это как динамика супротив статики. Но любой план или бюджет без системы изменений - досужая игрушка (см неопределенность планирования)

[folio]

Директор-нормальный пробой в системе. Можно прийти к нему и получить подпись в обход всех процедур. В принципе, это его работа, делать исключения из правил. Защита одна: дураки среди директоров редкость.
Ну а если не повезло-тут ничего не поможет

Моё суждение основано на предоставленных Вами данных. Обоснование своего субъективного вывода я уже озвучил.

По ЗИ-02 как-то совсем непросто сформировать базу (предпосылок) для окончательного суждения при принятии решения об утверждении.

???
Чтоб не нивелировалось, система изменений должна быть надежной
Создать первую версию СГЗ не слишком сложно. А вот не дать ей расползтись-в разы сложнее, это как динамика супротив статики. Но любой план или бюджет без системы изменений - досужая игрушка (см неопределенность планирования)

Про необходимость изменений - полностью согласен. Вот про расползание я и пытался потолковать. Да и позволю себе вольность, но Вы сами подтвердили мотивы моего суждения. [Создать первую версию СГЗ не слишком сложно.... А вот не дать ей расползтись-в разы сложнее]

З.Ы. Я, честно говоря, просто, наверно недопониманию, почему заветная плюшка (изменение) достаётся так просто.

[Andruxa]

А вот не дать ей расползтись-в разы сложнее, это как динамика супротив статики. Но любой план или бюджет без системы изменений - досужая игрушка (см неопределенность планирования)

Должен быть интегральный критерий для всего плана/бюджета, который бы говорил, "встраивать" изменение, или нет.

[Сахават]

Должен быть интегральный критерий для всего плана/бюджета, который бы говорил, "встраивать" изменение, или нет.

что невозможно пока не разберешься как появляются ЛИМИТЫ
заявка - 100 молотков
ответ - блин , у тебя же всего три дачи!?

[Михаил_Шустер]

Должен быть интегральный критерий

Вот главный интегральный отчет, думаю все понятно
Слева руководители, ответственные за направления
Под руководителями - подразделения, распоряжающиеся лимитами от их имени
Заказчики скрыты в агрегатах, там свои отчеты и ОЛАПы
Цифры и прочие подробности вытерты из-за товарища майора

[Михаил_Шустер]

что невозможно пока не разберешься как появляются ЛИМИТЫ

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

[Andruxa]

что невозможно пока не разберешься как появляются ЛИМИТЫ
заявка - 100 молотков
ответ - блин , у тебя же всего три дачи!?

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

[Михаил_Шустер]

По ЗИ-02 как-то совсем непросто сформировать базу (предпосылок) для окончательного суждения при принятии решения об утверждении.

До директора вопрос доходит только при наличии договоренностей (согласовании) между заказчиком, снабженцем, ОЦПР, руководителем направления), где имеет место естественный конфликт интересов.
При отсутствии таковых, до директора доходит сформулированная проблема.

недопониманию, почему заветная плюшка (изменение) достаётся так просто

Просто процесс инициализации изменения не описан
Я не сторонник жестких планов, столь модных в государевой собственности. Они никогда не выполняются, с чем связано 90% государева геморроя. Важен баланс: слишком гибкий план - ручное управление, слишком жесткий - перерасход средств на глупости. Среди годовых планировщиков нет провидцев, это почему-то не все понимают.
Для постоянных и разовых заявок разная неопределенность, в этом направлении работа тоже ведется, про нее как нибудь потом.

[А.Б.]

... мне кажется интегральным критерием должен быть не лимит, а соотношение затраты/прибыль. А финансисты уже должны выкручиваться - находить деньги.

В реальности все наоборот и ремонтники пытаются выкрутиться с проведением ремонтов в рамках лимитов, установленных финансистами.

Правда не знаю, насколько это применимо к таким предприятиям, где работает Михаил.

Применимо но не применяется.

[folio]

Просто процесс инициализации изменения не описан
Я не сторонник жестких планов, столь модных в государевой собственности. Они никогда не выполняются, с чем связано 90% государева геморроя. Важен баланс: слишком гибкий план - ручное управление, слишком жесткий - перерасход средств на глупости.

Получается жизнь в состоянии постоянной неопределённости. В этом смысле ваша система учёта изменений точное отражение такого подхода.

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

[А.Б.]

Среди годовых планировщиков нет провидцев, это почему-то не все понимают.

Ничего необычного - сплошной Парето: 80% позиций планируются с точностью 20% и наоборот.

Ты даже сам где-то тут писал, что есть группы позиций по оборудованию которые повторяются из года в год и могут планироваться с точностью 99%. У нас так же.

[Михаил_Шустер]

насколько необходимо такое частое перебалансирование?

Это каждый решает для себя, своих условий. Кому и кобыла невеста: одному два раза в год-часто, другому раз в день-редко. Всякое "чересчур" любая система (отношений, т.е. культура) сама отторгает.
Тема "неопределенность", "горизонт планирования", набегающая волна, зпарос на изменение и т.п. много рассмотрена в РМВОКе и я практически со всем этим согласен. Про управление неопределенностями и соответствующие риски в форуме года 3 назад обсуждалось

Однако, основная позиция - за каждым проектом (направлением, лимитом) должен стоять конкретный смотрящий ФИО. Который и обязан установить надлежащий порядок в том числе - по вопросу перебалансирования.
А у ФИО на плече должна быть рука друга. Одна. Потому что вторая занята.
Пистолетом

[Михайло]

Я не осилил последние 3 или 4 страницы повалившего флуда, просто дам две достаточно серьезные ссылки, которые позволят понять разницу между управлением изменениями (change management) и управлением интеграцией проекта (integration management):
http://businesslearning.ru/CoursFrm.asp?actid=175
http://www.intuit.ru/department/itmngt/changemanage/1/

[Михаил_Шустер]

Я не осилил последние 3 или 4 страницы повалившего флуда

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