я не в курсе_ что имеется ввиду?Цитата:
Сообщение от Михаил_Шустер
Вид для печати
я не в курсе_ что имеется ввиду?Цитата:
Сообщение от Михаил_Шустер
имхо корреляцию любого природного явления с любой социальной активностью можно найти всегда-Цитата:
Сообщение от Елена И. Яковлева
тут главное исторические факты правильно подбирать-
_______-
например - берем на такое-то число такое-то природное явление и ищем в мире - была ли социальная активность-
Я думаю_ что это по аналогии с особенностью нашей памяти- Например_ елси событие негативное произошло после черной кошки - то оно запоминается и заносится "в статистику"_ а если само по себе - то произошло и прозошло_ никакого влияния на статистику-
Уважаемый друг_
могли бы Вы как автор ветки подвести итог беседы?
к какому выводу пришли для ответа на свой первоначальный вопрос? What s the difference between CM & PM?
Цитата:
Сообщение от Александр Болдин- 30
Цитата:
Сообщение от Александр Болдин - 51
Помните, глупость заразна. Пытаясь ответить на глупые вопросы вы незаметно для себя становитесь глупее ... и чем дальше, тем больше.Цитата:
Сообщение от Елена И.
Поэтому все мои посты в этой ветке - это не ответы, а оценочные суждения. :)
Это было бы здорово, но это не так - выборка одна.Цитата:
Сообщение от eliferov
Так называемые "рыночная экономика", "эффективные холдинги" и т.п. - существуют только в книжках про бизнес ... которые пишут уставшие от борьбы с дремучим невежеством консультанты.
Все холдинги создаются для концентрации власти. Соответственно, на позиции руководителей внизу назначаются удобные посредственности. Эти организмы обладают уникальными свойством: гибкость по направлению вверх сочетается у них с твердостью по направлению вниз.
Если ты обслуживание данного феномена называешь "система власти" так и скажи. :)
Значит моя выборка пошире.Цитата:
Сообщение от Александр Болдин
Это для тебя они все одинаковые, а мне приходится работать с очень разными организациями, у топов которых потребность во власти совершенно разная. Например недавно был пример с одной очень крупной компанией, не заметил я у них потребности в "системе власти", их реально интересовало управление (кроме 2-3 чел из 15-20).
1) Они не одинаковые: люди все разные, но условия часто схожие. А схожие условия формируют повышенную потребность в схожих людях ... Вот и происходит концентрация (или выражаясь языком науки - отстой).Цитата:
Сообщение от eliferov
2) Исключения лишь подтверждают правило.
Так_вроде картина немного проясняется
похоже_ что наш Change Management Commitee представлял из себя на самом деле Project management office
PMO mas informacion
_______________________________-
Вот еще интересная ссылка - там внизу про сравнение проджэкт менеджера и проджэект менеджмент офис - все так и есть (точнее было в той компании)-
http://www.zinsin.ru/insur/lav_71_9....8b9d5721869b5b
Это как анекдот про двух кобр
Две кобры читают справочник по змеям.
Одна говорит:
- Смотри-ка, тут написано, что мы ядовитые!
Вторая, просветленно:
- Внезапно многие события моей жизни стали мне понятны...
Близко, практически одно и то же. Я бы сказал так. И там и там цель - повышение ROI или каких-то еще фин. попугаев по типу стоимости. Там, где матрица тяготеет к сильной, там нужен PMO, там где к слабой, там нужен Change Management Office.Цитата:
Сообщение от Елена И.
Оговорка правильная, "Часто" - но далеко не всегда. Условия задаются той самой головой у рыбы, которая.... не всегда хочет гнить. http://forum.cfin.ru/images/icons/icon7.gifЦитата:
Сообщение от Александр Болдин
С уважением Виталий.
Тезисы выступления А.И. Левенчука на круглом столе "Зрелость в управлении проектами - цель или средство".
(http://www.slideshare.net/ailev/ss-8126587 )
1. Методов проектного управления множество, и это нельзя недооценивать. Более того, этих методов уже четыре поколения :
-- первое, где проектами называлось отнюдь не всё, и важна была роль сетевого планирования.
-- второе, где проектами обзывается всё что угодно, и проектное управление шовинистически захватывает большие куски других дисциплин
-- третье, где проекты, программы, и вообще менеджмент тесно склеены друг с другом (собственно, это деление на поколение как раз обсуждается в документах методологии третьего поколения P2M - http://www.pmaj.or.jp/ENG/P2M_Download.htm).
-- четвертое, моделе-ориентированное - где модели продукта и модели проекта (project) тесно связываются друг с другом, а методология опирается больше на динамическое планирование и last planners ("полевых инженеров"), нежели на предварительное и first planners (специальных планировщиков в штаб-квартире). Грубо говоря, планирование становится еще более инженерным, а менеджмент - еще более личностно-ориентированным.
2. Перед тем, как интересоваться зрелостью проектного управления, нужно поинтересоваться, зрелость какого именно проектного управления имеется ввиду. Очень зрелое сетевое планирование (первое поколение) вполне может уступить очень незрелому применению критической цепи из теории ограничений (третье поколение). То есть управление технологией (выбор и постановка технологии, а затем своевременная смена технологии на более прогрессивную) для проектного управления явно предшествует циклу непрерывного совершенствования, ведущего к зрелости выбранной технологии.
3. В силу "проектного шовинизма" сам предмет проектного управления стал совсем неохватным за счёт прихвата самых разных менеджерских дисциплин, и сейчас почти эквивалентен уже "просто менеджменту". Поэтому разговор о технологиях замыливается обсуждением общеменеджерских ситуаций, в которых специфика собственно проектного управления никак не проявляется. При этом зачастую забывается, что проектное управление более глубоко изучается в курсах инженерного менеджмента, нежели на курсах MBA - прежде всего за счет более глубокого изучения предмета исследования операций ("фабричной физики" - как потоки материалов и работ движутся по предприятию в ходе жизненного цикла продукции).
4. Четвертое (моделеориентированное) поколение пока еще очень молодо. Но сама тема планирования работ, основанная на технологических производственных моделях и моделях продуктов уже поднимается во многих и многих организациях. Так, активно обсуждается (а кое-где уже делается) порождение графика работ из 3D-модели, где каждая деталька должна быть вовремя закуплена, вовремя выдана в монтаж, вовремя и без проблем с ресурсами смонтирована, вовремя проверена - и так для всего инженерного объекта в целом. План работ включает в себя не только плашку из диаграммы Гантта, но и мультфильм, где рабочему показывается, какую именно работу и с какими именно объектами делает этот рабочий, и за какое время ожидается, что он эту работу выполнит.
5. Всё вышесказанное относится, увы, больше к более-менее понимаемым строительно-монтажным, машиностроительным и прочим "строительным/сборочным" по типу работам. Ежели речь идёт о творческой работе типа проектирования/конструирования, то тоже можно говорить о проектном управлении, но опять-таки, меняются его методы. Управление коллективным проектированием (collaborative design) и управление сооружением (construction management) - это совсем разные управления, и методы управления проектами (project) в их составе будут крайне разные. Кстати, проектный шовинизм приводит к тому, что управление проектированием и управление сооружением часто включают внутрь проектного управления, а не наоборот - задумайтесь, насколько это полезно для дела.
...
В ИТ давно проектный "моделизм" присутствует, язычок UML даже для этого есть, для проектирования. Насчет мультиков - это здорово, всегда любил спрашивать "а что ты будешь делать"? :) Спасибо за обзор.
Насчет шовинизма - это да. Вобрал в себя PM много, и я считаю много лишнего, правда из PMBoK ничего не вырежешь. Зато книжек развелось про "персонал проекта", как его мотивировать, как "быть лидером", и черти чего вообще много... прямо надоедает иногда.
А еще PMBoK мне никогда не нравился именно тем, что ЖЦ продукта там не учитывался. Я сторонник инвест. проектирования, где весь ЖЦ продукта охватывается. Так что изменения меня только радуют. Ура.
Нифига он не понимает ни в моделировании, не в планировании.Цитата:
Сообщение от Александр Болдин
Надо ж блин - construction management!!! Единственное модельное отличие от не construction management - мобильность и стационарности (т.е., поток несет не ресурсы, а процессоры).
Пора все же читать Балакшина. :):):)
Строго говоря, UML - это промежуточный результат на пути воплощения мечты группы OMG (Буч, Йордан и др.) о Model Driven Archutecture... Т.е. об архитектуре информационной системы, полностью управляемой моделью.Цитата:
Сообщение от Andruxa
Однако, после создания UML должно было пройти еще 10 лет, прежде чем была создана платформа для интеграции - стандарт ISO 15926.
Аналогично. Дело в том, что в РМВОКе жизненный цикл продукта начинается с момента завершения проекта - то есть находится вне системы. В отличие от мечтаний разработчиков РМВОК, в реальной ситуации жизненный цикл продукта находится внутри управления проектом, хотя и начинается со смещением относительно старта проекта.Цитата:
Сообщение от Andruxa
Вот и появляются в результате этого такие чудеса как проект поддержки предоставления услуги поддержки. :) А инвестиции должен отбивать покупатель. Правда все же есть умные менеджеры по продажам все же считают ROI и прочие NPV для продуктов. Но это редкость даже для крупных компаний.
Лет всего 10 назад я гораздо лучше разбирался во всех без исключения предметах, связанных с управлением. Похоже, научный менеджмент тоже движется от "какие все дураки" к "кажется все немного сложнее", расшатывая картину мироздания в взрывая моск.
Так, глядишь, придем к пониманию того, что главное-это двигаться в мэйнстриме, послав на фиг средне-, дальне-, а еще дальше- стратегическое планирование. Формула успеха предельно проста: хочешь быть успешным - будь как все, но лучше всех. Не думай, что можно чего-то достичь, будучи перпендикулярным мэйнстриму.
Нет иной логики, чем логика мэйнстрима. Если после заявления Обамы цены на нефть просели, то вовсе не потому, что есть связь между тем, что он говорит и тем, что происходит с нефтью на самом деле. Связь находится совсем в другом месте: не "Обама-нефть", а "Обама-действие спекулянтов". Знать нужно не "как поведет себя нефть", а "как поведут себя спекулянты"
Что же такое миссии, перспективное планирование? -просто мантры уставших консультантов для тех, кто еще способен слушать. Дальше происходит вот что: микроскопическая доля из тех, кто услышал, попробовал и у них получилось. Потому что майнстриму тоже нужны исключения, чтобы развиваться. Майнстрим оценил успех и пошел за ним. А у кого не получилось-те в очереди за бесплатным супом. Потому что система бездушна и реагирует только на результат.
Прикол в том, что без дальнего планирования развитие действительно невозможно. Но чем дальше планирование - тем больше риски и тем меньше организаций, способных позволить себе такое удовольствие. Смотрите: в экономии бензина наметился мэйнстрим: гибриды и аккумуляторы. Лидеры не ищут перпендикулярных путей, а движутся там, где возможна суперсерия. Даже если и есть перпендикулярное решение (зола АЭС, слезы девственниц, раковый свист), оно будет лежать до тех пор, пока...
В этом случае Левенчук прав: между управлением проектом проектирования электростанции и управлением проектом строительства электростанции есть принципиальная разница. Что характерно: в первом случае РМВОК работает, а во втором - нет.Цитата:
Сообщение от Сахават
Причем, здесь Левенчук говорит о проектировании очень узко - как о collaborative design (совместное конструирование), тщательно обходя момент на котором у американцев случился когнитивный диссонанс с коллективным выносом мозга - вопрос различия между engineering и design.
фигня тожеЦитата:
Сообщение от Александр Болдин
без определения интерфейсов никакая совместная работа невозможна
интерфейс опредлеятся централизованно
а дальше опять каждый кусок делается централизованно, (возможно) на другом уровне
Все фигня, коме пчел ... :)Цитата:
Сообщение от Сахават
Интерфейсы утверждаются централизовано, но разрабатываются и согласуются исполнителями ... вернее одним исполнителем, который потом навязывает свою волю прочим. Чтобы заработало надо только так - иначе интерфейс так и останется бесполезной бумажкой с начальственными подписями.
Чтобы объяснить разницу между collaborative design и construction management нужно чтобы тот, кому объясняют, понимал что есть то и другое. Инача все объяснения будут лишь сотрясением воздуха.
Но
Я понимаю, Шустер понимает, ... но мне не надо объяснять Шустеру в чем соль - он и так знает. Такая вот фигня. :)
Трошки сменю тему. Тоже изменения, но...
Прикладная задача, тема старинная, скучнейшая управление изменениями документов. Полтора часа с программерами чесали совокупную рэпу, разошлись практически ни с чем.
В качества документа рассматривается утвержденная копия базы данных, где записью является заявка на закупку товара или услуги; в совокупности они образуют Сводную Годовую Заявку (СГЗ). Которая всегда должна соответствовать Годовым Лимитам Финансирования (имеют сложную структуру, фактически бюджетирование). Лимиты могут меняться, а заявки-дорожать или дешеветь, терять актуальность, появляться внеплановыми, перераспределяться между закупающими подразделениями. В общем, с помощью системы изменений должен обеспечиваться баланс "лимит-заявка" и на любой момент времени должно быть четко известно, кому и что надо покупать.
Множество систем автоматизации не содержат не то, что докфло, но элементарных элементов управления изменениями. Почему это так-отдельный вопрос, который даже в могучей Примавере решен падецки через пересмотр версий (хотя возможно я просто не понимаю). В древнем Парусе вопрос мало того, что не решен никак, но еще и...
В общем, есть изменения и есть пересмотры. Для первых оформляются Извещения об изменениях, для вторых - документ переиздают и согласовывают заново. Первое - репликации, второе - полная замена версии, возможно даже со стиранием ссылок на реплики.
Изменения удобны, когда пользователь знает исходный документ, а в извещении видит только, что изменилось. Пересмотры удобны пользователю, который либо видит документ впервые, либо пользуется им в онлайне: читаю-делаю-читаю-... Есть комбинации способов - например, выделение измененных фрагментов. Изменение возможно как "редактировать", либо как "добавить-и-старнировать", принципиальная разница в нумерации строк.
Программеры говорят, а какая разница? Давайте будем любое утвержденное изменение сохранять, как пересмотр. То есть, каждый раз перезаписывать БД, как версию. Ресурсы-не вопрос, если что-будем хранить на дисках. Тогда изменение - это отчет "было-стало" при сравнении текущей версии с любой предыдущей, или предыдущих между собой. Можно обыграть номера версий: аналог утвержденной бумаги - V1, V2,.., изменение - V1.1, V1.2...
Минус (кроме ресурсов) - путаница (как сейчас) в выборе версии для сравнения и, соответственно, возможность злоупотреблений. Плюс-основной потребитель является законодателем и не приемлет никаких других форм изменений, кроме файла Эксель в самой последней редакции (причем его логику я так и не понял ввиду отсутствия единой официальной точки зрения)
Вопрос:
1. Спасибо, что прочитали и извините. В голове сумбур, когда проговоришь задачу-помогает. Пока не помогло, вопрос так и не сформулирован
2. Если кому есть что сказать-подойдет любой уровень абстракции, может моск куда-нибудь да и подтолкнется
Лучше оставитьЦитата:
Сообщение от Михаил_Шустер
Редакция (несущественные уточняющие изменения)
Версия (глобальный пересмотр)
(ресурсы и т.д. второстепенно)
Задача неразрешима современными техническими одномерными линейными средствами. Нейроны мозга способны создавать многомерные связи. Следовательно, под Вашу техническую конструкцию нужен будет ЕЩЕ по кр. мере один живой человек, а не компьютер.Цитата:
Сообщение от Михаил_Шустер
Программисты разъехались, остались программеры?Цитата:
Сообщение от Михаил_Шустер
Первая таблица - Таблица сводных годовых заявок. Дата СГЗ первый ключ.Цитата:
Сообщение от Михаил_Шустер
Вторая таблица - Таблица истории заявок на закупку.
Дата заявки - второй (подчиненный ключ).
Дальше еще нужна бюджетная классификация заявок. Тоже ключ в историю заявок.
Если для каждой строки бюджетной классификации может быть одна заявка - достаточно выборки последнего элемента строки бюджетной классификации.
Если заявок на одну строку может быть много - то вводится поле "аннулировано", которое содержит истину при пересмотре (отзыве) конкретной заявки.
Если поле "аннулировано" ввести нельзя - то для каждой аннулированной заявки вводится такая же с отрицательным знаком. И тогда выборка не по последнему, а по сумме.
Собственно в таком примерно виде версионность бюджетов часто и реализуется.
Это с какой поры реляционная СУБД стала одномерной и линейной?Цитата:
Сообщение от Елена И. Яковлева
;) Это же не таблица в Йокселе.
С момента ее (реляционной модели данных) реализации на линейных одномерных ТС.Цитата:
Сообщение от Genn
Что то там было про машину Тьюринга, или Тьюнинга.Цитата:
Сообщение от Елена И. Яковлева
8Р
Спасибо:)Цитата:
Сообщение от Genn
Однако, задачу нужно решить средствами Парус Предприятие, активно пользуемой на живых данных сотнями юзеров. В Парусе нет управления репликациями, версионностью, отчетов типа "Было-Стало"; это (кроме репликаций) сделали сами.
Мы не можем себе позволить писать крутой функционал, задача должна быть решена подручными средствами. Отдельное несложное приложение и импорт-экспорт. Возможно, Эксель. Разработчик проблему признает и готов решить за деньги, мы платим, а он потом тиражирует. Хрен ему, надо было раньше думать. Не понимаю, как вообще можно всерьез продавать системы без динамики.
Ты сводишь к интерфейсной задаче?Цитата:
Сообщение от Сахават
Приоритеты? Основных переменных параметров всего 4: номенклатура, цена, количество, подразделение-снабженец, все равноприоритетные. Про остальные пока не задумывались: их корректируют на стадии договорной спецификации, согласовывая на бумаге. Это важный раздел, но я не о нем.
конечно, и про архитектуру фон Неймана. А еще - всяческое непрекращающееся сопровождение и доработка приложений ...Цитата:
Сообщение от Genn
Вот за изучение функционала Паруса я деньги возьму.Цитата:
Сообщение от Михаил_Шустер
В Йокселе это ложится в 2 рабочих листа.Цитата:
Сообщение от Михаил_Шустер
Но требует дисциплины оператора рабочей книги.
В Аксесе - тоже реализуется довольно просто.
Вам просто надо найти программиста - белая логика на первой или второй базовых функциях в модели А. (ДонКихот, Робеспьер, Максим, Жуков) Для вас - как возможного представителя Гаммы - это может быть и сложно, но ... просто найдите адекватного исполнителя.
... или пишите в л/с.
Наверное надо было предупредить. Имеет место реально работающая система с нехилым функционалом на предприятии в 7500 человек (в т.ч. 70 служба IT, в т.ч. сильные программеры). И это не понты ЕРП внедряльников, а полновесный спрут, без которого уже давно никто ни шагу. Изменения тоже работают, но некрасиво, трудозатратно и с нарушениями правил (например, могут в обход процедуры изменить заявку, на которую есть договор).
Я думаю, задачу будем решать так. Цех-заказчик создает в отдельном приложении заголовок (номер, дата) заявки на изменение своей сводной заявки и ее спецификацию. Приложение блокирует нарушение правил и выгружает выбранное в шаблон Экселевого файла. В Экселе заказчик проводит моделирование, пытаясь скомпенсировать изменение через "Удалить-Изменить" ("Добавить" было сделано в Парусе и скинуто приложением в Эксель). Когда все закончено, заказчик экспортирует (транзакция) Эксель в приложение, причем если он перемудрил, экспорт не пройдет (а не надо быть таким хитро*опым). Далее из приложения он получает распечатку Заявки на изменение, защищенную от подделки. Бумагу согласовывают и утверждают, затем приложением "проводят" по Парусу.
Искомый Эксель хранится, как реплика и при этом входит в текущую версию БД (которая "стало") Парус; все предыдущие версии ("было") хранятся отдельно. Решение о сохранении новой версии и присвоении ей нового номера принимает тот, кто отвечает за взаимодействие с Центром. Он же в настройках отчета "было-стало" и указывает, какую версию принимать за "было". То есть, в двух БД достаточно первички, так что изменение или пересмотр-задача на интерфейс. Как то так.
Как узнать что выбрать?Цитата:
Сообщение от Михаил_Шустер
В какую версию добавили?Цитата:
Сообщение от Михаил_Шустер
а куда добавили, если не знали что "было"?Цитата:
Сообщение от Михаил_Шустер
Вощем у тебя дерево, один терминальный узел которого является "стало".
И если терминальных узлов > 1 то должна быть правило выбора - или выбрать последнее "стало" или любой узел начиная от корня по какому то критерию.
Михалыч, может быть мнение о крутости ваших программистов слегка э ... субъективное?
Вообще-то такие задачки они должны щелкать как семечки, причем средствами Паруса ... Хотя я не знаю какая у вас пыхтит версия этого динозавера - если совсем юрского периода, то могут быть проблемы с внутренними доработками.
Насколько я понял твою задачу, это что-то типа:
1. Сбор заявок на закупки.
2. Консолидация заявок в ГКПЗ (годовую комплексную программу закупок) и ее утверждение как документ.
3. Внесение изменений в заявку и/или новых заявок.
- Регистрация запроса на изменение.
- Проверка влияния на другие заявки и консолидированные итоги ГКПЗ.
- Согласование запроса (принять-отклонить-заморозить).
4. Завершение операционного дня: Оценка общего отклонения по ГКПЗ (плюс-минус 10% или сколько у вас там), если превышает - утверждение новой версии ГКПЗ. Старые сохраняются с возможностью отката.
Как видишь, ничего мега-сложного. Нужно только кое-что поменять в консерватории (построить закупщиков), ну и договориться с программистами чтобы они автоматизировали не то что им хочется, а то что необходимо.
Как узнал? У нас тут действительно затруднение:) Но это рабочий моментЦитата:
Сообщение от Сахават
А как узнать - мышью ткнуть, как еще? Или ты насчет "допустимо ли?" - тут никакого искусственного интеллекта. Человек отвечает-человек тыкает. Мы нашли остроумную замену нормативам и не вернемся к ним, ты об этом? Заявки делятся на постоянные и разовые. Постоянные - тематические, хорошо структурированы, это очень похоже на нормативы, но мягче. А от ошибок страхует наглядность.
Это еще не версия, а таблица для моделирования. Становится репликой после того, как из нее сделан экспорт. Хранится в БД приложения. Вопрос версионности решается не здесь, а в Парусе, когда из имеющихся данных на выбранную дату и повод, делается официальный срез, который и становится "было"Цитата:
Сообщение от Сахават
Ночью, вместо чтоб спать, додумал: в модельной таблице должны быть две колонки количества, было и стало. Корректировать можно только последнюю.Цитата:
Сообщение от Сахават
Правило простое: кто отвечает, тот и выбирает.Цитата:
Сообщение от Сахават
Это нормально. Незачем автоматизировать лишнее
Пришли программеры и все испортили. Приложение будут в Парусе писать, без Экселя:)
Концептуально все так же, но лучше: есть две копии записи: до и после изменения
Форум последнее время скучноват, предлагаю типа кейс для оживлежу.
Чисто кому интересно. Ну... как кроссворд, где все ответы, как у Шекли, правильные и неправильные одновременно.
Предложения-замечания-жалобы-рассуждения-обобщения-КГАМ... в принципе показан срез существенной части системы управления через подсистему ее изменений.
ЗЫ. Обвинения типо "хочете мудрость забесплатно" с негодованием отметаю.
Сложновато-абстрактновато.Цитата:
Сообщение от Михаил_Шустер
Предлагаю описать через диаграммы ЖЦ заявки на изменение, совокупной годовой заявки.
Здесь, по-моему, самое главное, это алгоритм принятия/непринятия заявки полуавтоматизированно (укладывается - принимаем, нет - не принимаем), и приоритеты должен назначать утверждающий (утверждающие).
Просто слишком много деталей за кадром.Цитата:
Сообщение от Andruxa
ЖЦ заявки, как предмета изменений в произвольной нотацииЦитата:
Сообщение от Andruxa
Удобна для презентаций, позже покажу почему
Да. Плюс надежный учет, блокировка отмененных и удобства пользователей.Цитата:
Сообщение от Andruxa
Комент, просто комент:Цитата:
Сообщение от Михаил_Шустер
Ого-го, у вас Ген дир прямо мегамозг какой-то. По ЗИ-02 как-то совсем непросто сформировать базу для окончательного суждения при принятии решения об утверждении.
Вы кстати ЗИ-06 забыли добавить.
Это к первому файлу или ко второму?Цитата:
Сообщение от folio
Второй (ЖЦ) - это собственно процесс, который должен быть обслужен системой изменений. Если комент к нему - вроде все нормально: директор только разруливает вопросы, которые РН (руководители направлений) не смогли решить своей властью. Это делается на совещаниях. Если (когда) вопросов нет, директор подписывает талмуд, глядя только на первый лист (агрегаты)
На изменениях-аналогично. Если заявка скомпенсирована (по статье не произошло удорожания) и руководители направлений подписали-утверждает не разбираясь. Предлагал ему оставить за собой утверждение только проблемных изменений - не хочет пока, его дело.
Я про п 3.3 и 3.4 положения и приложение б (т.е. первый файл).
Обычный порядок. Директор смотрит общую цифру небаланса и наличие подписей. Если ОК-подписывает, если нет-его дело: подписать, отказать, позвонить, вызвать, написать резолюциюЦитата:
Сообщение от folio
Изменения заявки в виде мультика для обучения (фрагмент)
(заодно диагностика, лечение и самопроверка)
Когда занимался аудитом, все пытался выдумать форму отчета, чтоб наглядно донести проблемы и способы их устранения. Находил обычно много, но в таблице находки смазывались, часть выносил в общие положения, но ни на чем толком не остановился.
Мультик мне нравится больше всего. Пока. На примере он весь в звездочку-такова ситуация, но возможны варианты - вот другой пример, без подробностей
Забыл на всякий случай сказать
Перед просмотром давите F5
По ощущениям - это слабое звено (одно из). Смысл ЖЦ нивелируется возможностью внесения изменений.Цитата:
Сообщение от Михаил_Шустер
Директор-нормальный пробой в системе. Можно прийти к нему и получить подпись в обход всех процедур. В принципе, это его работа, делать исключения из правил. Защита одна: дураки среди директоров редкость.Цитата:
Сообщение от folio
Ну а если не повезло-тут ничего не поможет
???Цитата:
Сообщение от folio
Чтоб не нивелировалось, система изменений должна быть надежной
Создать первую версию СГЗ не слишком сложно. А вот не дать ей расползтись-в разы сложнее, это как динамика супротив статики. Но любой план или бюджет без системы изменений - досужая игрушка (см неопределенность планирования)
Моё суждение основано на предоставленных Вами данных. Обоснование своего субъективного вывода я уже озвучил.Цитата:
Сообщение от Михаил_Шустер
По ЗИ-02 как-то совсем непросто сформировать базу (предпосылок) для окончательного суждения при принятии решения об утверждении.
Про необходимость изменений - полностью согласен. Вот про расползание я и пытался потолковать. Да и позволю себе вольность, но Вы сами подтвердили мотивы моего суждения. [Создать первую версию СГЗ не слишком сложно.... А вот не дать ей расползтись-в разы сложнее]Цитата:
Сообщение от Михаил_Шустер
З.Ы. Я, честно говоря, просто, наверно недопониманию, почему заветная плюшка (изменение) достаётся так просто.
Должен быть интегральный критерий для всего плана/бюджета, который бы говорил, "встраивать" изменение, или нет.Цитата:
Сообщение от Михаил_Шустер
что невозможно пока не разберешься как появляются ЛИМИТЫ :)Цитата:
Сообщение от Andruxa
заявка - 100 молотков
ответ - блин , у тебя же всего три дачи!?