Практика проектного управления
26 октября 2010 в 13:19

Практика проектного управления

Здравствуйте, уважаемые коллеги!
Интересно в высшей степени познакомиться с примерами успешной реализации практики проектного управления в конкретной компании. В силу моей нынешней профессиональной специфики, особый интерес представляет строительный бизнес. Какие аспекты хотелось затронуть в обсуждении:

  • информационная инфраструктура (логика движения информации и документов, хранение информации и знаний);
  • порядок принятия решений, распределение полномочий и ответственности, решения в части организационной структуры;
  • мотивационные механизмы;
  • порядок решения конфликтных ситуаций;
  • уровень формализованности процедур и порядок управления формализацией;
  • использование IT-инструментария, плюсы/минусы.
    Всем заранее признателен за участие.
3959
Комментарии (70)
  • 26 октября 2010 в 21:09 • #
    Вениамин Балашов

    Видимо, для включения драйва, начать нужно с себя, т.е. с компании, где я тружусь. К сожалению, по причине катастрофической нехватки времени, в том числе и из-за "вала текучки", которая является следствием отсутствия системы планирования, описывать аспекты нашей "системы проектноего управления" буду по-модульно.
    Начну с информационной инфраструктуры - как вам, увыажаемые, такой подход: все внутренние письма (между отдельными функциональными подразделениями) ходят "в бумаге" с большим набором подписей и виз, при этом такой инструмент (хотя бы), как Ms Outlook, отвергается для этих целей напрочь? Т.е. присутсвует во всей красе фундамент функционально-иерархической структуры.
    А как у вас?

  • 19 декабря 2011 в 12:22 • #
    Вячеслав Шабанов

    Здравствуйте Вениамин, «вал текучки» можно устранить одним единственным способом –
    созданием и введением в действие системы менеджмента качества (СМК) на
    основе международного стандарта (МС) ИСО 9001:2008 «СМК. Требования».
    А «проектное управление» проводить соответственно на основе МС
    ИСО 10006:2003 «СМК. Руководство по менеджменту качества при проектировании» и/или
    американскому национальному стандарту (АНС) ANSI/PMI 99-001–2004
    «Руководство к Своду знаний по управлению проектами» также в СМК организации.
    С 2000 г. принцип описания производственной деятельности в СМК по
    элементам системы качества (или «по-модульно») заменен на
    принцип «процессного подхода» к СМК, производственные процессы, в
    которой можно описывать на основе
    «Технологии структурного анализа и проектирования» (SADT) с
    языком функционального моделирования (ФМ) процессов IDEF0.
    Что касается «информационной инфраструктуры», то с наступлением
    эры Интернета «бумагу» необходимо постепенно заменять на
    электронный документооборот в корпоративной сети – интранет.
    Кроме того, «вал текучки» необходимо систематически уменьшать
    проведением предупреждающих и корректирующих действий
    на всех уровнях управления в процессе создания и введения в
    действие СМК организации на основе соответствующих
    требований МС ИСО 9001 и руководящих указаний по их оптимальной
    реализации в процессах СМК в соответствии с МС ИСО 9004:2009
    «Менеджмент для обеспечения устойчивого успеха организации.
    Подход к менеджменту качества».
    Более подробно с этим и другими подходами можно ознакомиться на
    страницах моего блога:
    http://spooo.ru/blogs/user/qm-master-shs

  • 25 января 2012 в 17:12 • #
    Вячеслав Шабанов

    Здравствуйте Вениамин.
    В своей вступительной статье Вы написали:
    «Интересно в высшей степени познакомиться с примерами успешной реализации практики проектного управления в
    конкретной компании».
    Вначале на комментарии читателей Вы как-то реагировали, но уже
    БОЛЕЕ ГОДА Вы перестали каким-либо образом проявлять себя, не смотря на то, что
    читатели сообщали ВСЕМ НАМ о примерах
    «успешной реализации практики проектного управления в конкретной компании».

    Это что? Вы потеряли ДРАЙВ или
    «Практика проектного управления» по Вашему мнению, впала в
    «ЛЕТАРГИЧЕСКИЙ СОН»?

    Если Вы ЖИВЫ и ЗДОРОВЫ, во что НАМ ВСЕМ, я надеюсь, хотелось бы верить, –
    отзовитесь, ПОЖАЛУЙСТА.

  • 26 октября 2010 в 21:12 • #
    Вениамин Балашов

    Прошу прощения за некоторые опечатки - пишу на нетбуке в транспорте:)

  • 28 октября 2010 в 11:07 • #
    Геннадий Чернецов

    Здравствуйте Вениамин! Мы за полтора месяца поставили российскую систему А2:Управление проектами на заводе "Воронежсинтезкаучук" для сопровождение проекта строительства очистных сооружений. Около месяца ушло на перепланирование всего проекта в MS Project. Но одна ошибка здесь все-таки была. Мало времени дали на обучение, не включили компоненту "Управление изменениями". Хотя основную задачу решили - сдали объект за год.

  • 27 октября 2010 в 09:37 • #
    Даниял Закиров

    Здравствуйте, Вениамин!
    Тема, которую Вы затронули очень интересна и обширна.
    Вы хотите внедрить данную систему у себя?
    Пишите более подробно #

    C Уважением, Даниял Закиров
    +7 960-076-00-72

  • 27 октября 2010 в 22:13 • #
    Вениамин Балашов

    Вопрос не в том, чтоя хочу эту систему внедрить у себя.
    Как и что делать я прекрасно знаю. Вопрос в обсуждении именно результатов внедрения для формирования общедоступного Best Use.

  • 12 октября 2011 в 08:56 • #
    Эдуард Семенов

    Вениамин доброго дня!
    системы проектного менеджмента работают прекрасно - примеров тому много. (Зайдите на сайты разных разработчиков и продавцов инструментов по проектному управлению, почитайте отзывы, потом созвонитесь и пообщайтесь с представителями данных предприятий.
    Как я понимаю Вас волнует именно применение СИСТЕМЫ на Вашем предприятии. И как я понимаю основная проблема -это нежелание руководства чтото менять.
    В постах много обсудили технологии ввода данных и т.п.
    НО сначала нужно "заложить" фундамент т.е. перестроить оргструктуру предприятия под проектное управление (при этом конечно нужно понимать какой инструмент управления проектами будете применять). После чего уже "точить инструмент" под свои нужды. Но начинать нужно с руководства - не будет понимания и поддержки со стороны топ менеджмента -ничего не будет, и дело даже не в деньгах а в "человеческом факторе". Ну не нравится исполнителям прозрачность процессов, легче 25 раз завести один и тот же отчет в систему и потом валить вину за ошибки друг на друга, чем персонально отвечать за результат.
    Что касается эффективности методик проектного управления, то если бы они были неэффективны, они бы не "выжили" в течении столь длительного времени. Но инструментов много и понять какой использовать и что он вам даст можете только ВЫ САМИ.

  • 19 декабря 2011 в 12:48 • #
    Вячеслав Шабанов

    Вениамин, предлагаю Вам ознакомиться с моим видением того,
    «что» и «как» необходимо делать для устойчивого развития
    любой организации в условиях вступления России в ВТО в статье:
    «Как получить гарантированные преимущества в конкурентной борьбе?
    или
    Повышение эффективности производства – «что делать?» и «как делать?»
    на ВЗГЛЯД ПРОФЕССИОНАЛА со стороны».

  • 27 октября 2010 в 22:24 • #
    Вениамин Балашов

    Очередной пост в рамках модуля "информационная инфраструктура". Как известно, информация должна вводится один раз в месте, где она формируется (зарождается). Следствие этого правила - отчетность должна быть структурирована по критерию отсутсвия повтора ввода однотипной информации, минимизация неструктурированной информации. Несоблюдение этого простого равила приводит к тому, что исполнители готовят серию отчетов (для разных потребителей), причем эти отчеты дублируют информацию. Результат - нарушение целостности информации, удорожание процесса принятия управленческих решений.

  • 29 октября 2010 в 07:30 • #
    Рахимжан Султанкулов

    "исполнители готовят серию отчетов (для разных потребителей), причем эти отчеты дублируют информацию."
    Вениамин. Если они берут информацию из одного первичного источника, то ничего страшного нет. Бороться с обилием отчетов миссия почетная, но проигрышная. Нужен простой инструмент их формирования. Некрасиво. А я вот, например, не понимаю как это в Европе нет пыли на дорогах. Врут.

  • 29 октября 2010 в 09:16 • #
    Вениамин Балашов

    Вот о чем я и говорю - минимизировать объем неструктурированной информации, устранить дублирование структурированной информации, т.е. в ИТ-инфраструктуре иметь один отчет, аналог базы данных.
    Все, бегу на совещание:) Продолжим после:)

  • 16 декабря 2010 в 11:47 • #
    Виктор Отман

    Я думаю, тут Вы не правы. Смысл автоматизации, по-моему, в том, чтобы при единстве информации в базе данных каждый участник процесса получал отчет в наиболее удобном виде именно для него. Единый отчет, который Вы предлагаете, для каждого конкретного участника процесса будет содержать массу ненужной ИМЕННО ЕМУ информации, что затруднит его работу. Я видел немало примеров, когда управленцы вместо нормальной базы данных, из которой можно по запросу получить любой отчет, сооружали немыслимых размеров таблицы в Excel, работать с которыми оказывалось очень тяжело. Мне кажется, что это тупиковый путь.

  • 16 декабря 2010 в 21:27 • #
    Вениамин Балашов

    Я говорю не о едином отчете, а о том, что участник (ролевой) процесса готовит только один отчет. А для тог, чтобы его отчет попал в базу данных, отчет должен содержать минимум неструктурированной информации (упрощенно говоря, описательно текстового характера).
    Как происходит сейчас у нас - для каждого из потребителя отчета мы готовим свой отчет, при чем, если сравнивать атрибуты отчета (набор структурированной информации), то на 95 процентов они дублируют друг друга. Так в чем противоречие с тем, что я сказал выше? Таки вопросы давно стандартизированы в стандартах ISO (не путать с серией стандартов по качеству), а также в методологии ECM (управление корпоративным содержанием).

  • 17 декабря 2010 в 06:24 • #
    Виктор Отман

    "для каждого из потребителя отчета мы готовим свой отчет, причем, если сравнивать атрибуты отчета (набор структурированной информации), то на 95 процентов они дублируют друг друга."
    Не вижу в этом беды. При 95% совпадающих атрибутах они (отчеты), как правило, отличаются сортировкой и/или группировкой, и это существенно облегчает работу потребителям разных ролей. Но - главное - Вы, как я теперь понял, под отчетами имеете в виду входные данные для базы, а я понимал под отчетами - результаты, получаемые из базы. Этим и вызвана моя реплика, извините.

  • 17 декабря 2010 в 22:27 • #
    Вениамин Балашов

    Точно, глоссарная проблема!:) Я постоянно переключаюсь с языка IT на язык "не-IT". Как говорится, чем больше знаний, тем сложнее изъясняться. Дао, сказанное словами-уже не Дао:)
    Без проблем, извиняться не нужно, важен разговор.

  • 18 декабря 2010 в 04:29 • #
    Виктор Отман

    ОК!

  • 19 декабря 2011 в 13:45 • #
    Вячеслав Шабанов

    Вениамин, «объем неструктурированной информации» необходимо не «минимизировать», а
    ее вообще быть не должно.
    Для решения этой задачи можно использовать SADT с языком ФМ IDEF0, а также
    «Методологию информационного моделирования (ИМ)» с языком ИМ IDEF1X и
    соответствующие CASE (компьютерная поддержка реинжиниринга процессов) средства
    (BPwin – для ФМ и ERwin – для ИМ).
    Все выше названные методологии и соответствующие CASE-средства для
    некоммерческого использования можно бесплатно скачать в Интернете.

  • 9 января 2013 в 02:24 • #
    Кирилл Ярустов

    Вячеслав. Здравствуйте.
    Могу Вас попросить Вас указать ссылки на вышеприведенные программы.
    можно на почту: #

    Заранее Вам благодарен.

    С уважением, К.

  • 11 октября 2011 в 13:53 • #
    Вадим Чернов

    В фирме, в которой я работаю, это одна из самых больных точек. И наверное один из первых шагов, который нужно сделать нам.
    Как-то раз в свободное время я посчитал, что одна и та же однотипная информация ( в основном касается материалов), до 25 раз набивается, переписывается в различные заявки, спецификации, ведомости, счета и т.п. Соответственно это тянет нестыковки по времени и несвовременные передвижениям финансов, людей, машин. Никакого автоматизированного управления проектами нет, все держится на блокнотах и планерках). Никак не удается убедить руководство, что можно избежать многих проблем, это и срывы сроков, огромное количество рутинной работы нескольких исполнителей, нестыковки да и в финансовом плане, я думаю, потери имеются.
    Но пока так и работаем по старинке. Хотя директор нас и называет менеджерами проектов)), одновременно заявляя: "Денег нет!"
    P.s.
    Работаю в монтажной фирме по вентиляции и кондиционированию. Только недавно присоединился к сообществу, для ознакомления и получения полезной информации. Знаний в управлении проектами у меня пока мало.

  • 28 октября 2010 в 06:42 • #
    Валерий Артемьев

    Здравствуйте Вениамин. Я сейчас участвую в проекте сертификации части деятельности нашей компании по стандарту ISO 9001:2008. Сразу хочу отметить, что начинать необходимо с описания на бумаге бизнес-процессов компании, затем, после неоднократного анализа и утверждения руководством, призывать на помощь средства автоматизации. В противном случае Вы так и будете постоянно вязнуть в "текучке", постоянно внося коррективы в процесс автоматизации.

  • 28 октября 2010 в 12:48 • #
    Вениамин Балашов

    Приветствую, Вас, Валерий!
    Сразу хочу подкорректировать - сертификация по стандарту ISO 9001:2008 никакого отношения к проблеме управления проектами не имеет, это раз. Я являюсь членом "группы методологов" нашей системы качества. Уверяю Вас, эта деятельность к качеству не имеет никакого отношения. Второе - средства автоматизации также не являются панацеей в области проектного управления. Автоматизация - это всего лишь инструмент, увеличивающий скорость процессов за счет обеспечения целостности, доступности (ну, и конфиденциальности) информации. Третье - прежде чем начать моделирование бизнес-процессов, необходимо определиться, а что мы моделируем, куда бы хотели попасть в ближайшее будущее. Без этого не буде критерия оценки качества разработанных моделей, особенно там, где мало лиц, имеющих опыт оргструктурных преобразований, а такое часто встречается в наших структурах.
    И все же вопрос - какие положительные примеры (результативные) можно назвать при внедрении системы управленния проектами? Что удалось "вылечить"? С какими проблемами пришлось столкнуться вновь? Давайте сообща сформируем общедоступный Best Use.

  • 19 декабря 2011 в 18:00 • #
    Вячеслав Шабанов

    Вениамин, позволю себе не согласиться с Вашим утверждением:
    «сертификация по стандарту ISO 9001:2008 никакого отношения к проблеме управления проектами не имеет».
    Для правильного понимания этого вопроса, предлагаю Вам ознакомиться с п. 7.3
    «Проектирование и разработка» МС ИСО 9001.
    В процессе сертификации СМК организации также проверяется выполнение этого пункта
    ОБЯЗАТЕЛЬНЫХ ТРЕБОВАНИЙ выше названного МС.

  • 19 декабря 2011 в 15:50 • #
    Вячеслав Шабанов

    Здравствуйте, Валерий. Позвольте с Вами не согласиться в том, что
    «начинать необходимо с описания на бумаге бизнес-процессов компании».
    Как я уже сообщил выше – начинать необходимо с ФМ и ИМ (бизнес и не только)
    процессов производственной системы (ПС) или СМК любой организации и не на
    бумаге, а в электронном исполнении с использованием соответствующих CASE-средств.
    Что касается проекта(-ов) комплексной автоматизации процессов в ПС или СМК, то его
    также следует начинать с изучения и использования SADT, которая породила семейство МС
    CALS – КОМПЬЮТЕРНАЯ ПОДДЕРЖКА ЖИЗНЕННОГО ЦИКЛА ИЗДЕЛИЙ
    (любой ПРОДУКЦИИ и/или УСЛУГ любой государственной или коммерческой организации).
    Во главе этого семейства с 1994 г. введен в действие МС ИСО 10303-1–94
    «Системы автоматизации производства и их интеграция.
    Представление данных об изделии и обмен этими данными.
    Часть 1. Общие представления и основополагающие принципы».
    Примечания: 1. Все МС, на которые в моих комментариях даны ссылки
    имеют статус российских национальных стандартов (НС), например, упомянутый
    выше МС ИСО 10303-1–94 – НС ГОСТ Р ИСО 10303-1–99 (в России введен в действие с 1999 г.).
    2. Все МС и/или НС также для некоммерческого использования можно бесплатно скачать в Интернете.

  • 28 октября 2010 в 11:01 • #
    Геннадий Чернецов

    Я в первую очередь создаю техническую инфраструктуру путем установки российской платформы А2:Управление проектами. Это позволяет наладить оборот документов, которые относятся к проектной деятельности. С помощью этой системы создается возможность формирования команд, проведения дискуссий, управления рисками, проблемами, изменениями. Отдельные планы, созданные в MS Project выгружаются в эту систему в нужном месте (департамент, проект, подпроект, подзадача). Доступ к информации предоставлен всем участникам. Ту да же грузим регламенты и прочие документы.

  • 28 октября 2010 в 12:58 • #
    Вениамин Балашов

    Кстати, Геннадий! Было бы интересно полее подробно ознакомиться с функционалом и архтитектурными требованиями упоминаемой Вами платформы?

  • 28 октября 2010 в 19:34 • #
    Геннадий Чернецов

    Есть два варианта. Общаться со мной. Или зайти на сайт http://www.advanta-group.ru/about. Они разработчики (Екатеринбург), а я их партнер, специалист по методологии управления проектами.

  • 19 декабря 2011 в 17:10 • #
    Вячеслав Шабанов

    Геннадий, здравствуйте. В выше упомянутых мною СМК организаций,
    «оборот документов, которые относятся к проектной деятельности» организуется в
    соответствии с требованиями п. 4.2 «Требования к документации» МС ИСО 9001, а
    документооборот в соответствии с п. 4.2.3 «Управление документацией».
    Примечание. Проводить реинжиниринг ПС или создание СМК можно различными способами:
    - «свеху вниз» при наличии политической воли руководителя организации;
    - «снизу вверх» или «по горизонтали» на (всех) этапах жизненного цикла проекта,
    продукции и/или услуг по инициативе исполнителя(-ей) процесса(-ов), кстати,
    я начинал именно с этого способа после публикации и введения в действие
    1-ой версии (1987 г.) семейства МС ИСО 9000 – в результате чего, стал тем, кем стал;
    - с началом реализации какой либо установленной цели и/или решения определенных задач(-и), а
    также используя любые возможные комбинации выше приведенных способов.
    P.S. В случае, если Вы не готовы начать реинжинириг процессов, то рекомендую ознакомиться с
    книгой: «Практическое руководство по реинжинирингу бизнес-процессов» –
    авторы: Майк Робсон, Филип Уллах, которую также можно бесплатно скачать в Интернет.

  • 19 декабря 2011 в 17:19 • #
    Геннадий Чернецов

    К моей деятельности данный стандарт не имеет никакого отношения, равно, как и к управлению документами в проектах. Стандарты - это очень формальный подход.

  • 20 декабря 2011 в 12:19 • #
    Вячеслав Шабанов

    Геннадий, ох, как Вы ошибаетесь …
    Во-первых, относится какой-либо стандарт к конкретной прикладной области деятельности или
    не относится – зависит целиком и полностью от позиции разработчика, кроме
    обязательных стандартов, относящихся, например, к производству продукции двойного
    (или только военного) назначения.
    Во-вторых, стандарты – это формализованный (с точки зрения установления структуры, содержания и формы изложения) подход к документированию корпоративного,отраслевого, национального, межгосударственного и
    международного опыта, например, в области эффективной реализации процессов производства
    конкурентно способной продукции и/или предоставления услуг, превосходящих ожидания потребителей.
    Так, например, по ГОСТ 2.114–2006 вестись разработка и регистрация Технических условий (ТУ)
    может на одно конкретное изделие, материал, вещество или несколько конкретных изделий, материалов, веществ.
    При этом ТУ должны содержать разделы, расположенные в следующем порядке:

    • технические требования,
    • требования безопасности,
    • требования охраны окружающей среды,
    • правила приемки,
    • методы контроля,
    • правила транспортирования и хранения,
    • указания по эксплуатации,
    • гарантии изготовителя.
      А для осуществления разработки и регистрации ТУ в соответствующих органах необходимы следующие данные:
    • название и внешний вид изделия (продукции),
    • перечень модификаций продукции;
    • технические параметры продукции;
    • описание технологического процесса;
    • перечень комплектующих (состава для продовольственной, лекарственной и т.п. продукции);
    • код ОКПО изготовителя;
    • порядок и условия приемки продукции службой технического контроля предприятия-изготовителя;
    • методы и средства контроля качества продукции;
    • методы и средства испытаний продукции на предприятии;
    • способы упаковки и упаковочный материал;
    • документы, вкладываемые в упаковку;
    • виды транспорта, необходимые для перевозки продукции, и условия ее транспортировки;
    • условия хранения продукции;
    • условия эксплуатации продукции;
    • гарантийные сроки.
  • 28 октября 2010 в 12:51 • #
    Вениамин Балашов

    Правильно ли я Вас понял, что Вы берете некое типизированное решение, на основе которого корректируются внутренние бизнес-процессы?

  • 28 октября 2010 в 19:38 • #
    Геннадий Чернецов

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

  • 28 октября 2010 в 23:01 • #
    Вениамин Балашов

    Ну почему же не бывает, еще как бывает! Вспомним, хотя бы SAP с его набором типовых решений, при внедрении чего (в т.ч. из-за стоимости кастомизации) не типовое решение "прикручивается" к бизнесу, а бизнес "прикручивается" к типовому решению. Однако, почему-то, тема, заданная мною, никак не хочет выйти на ожидаемый результат, а именно, обсуждение того, что было "до того" и как стало "после", какие проблемы -"болячки" удалось вылечить благодаря внедрению системы проектного управления, с какими проблемами уже после внедрения пришлось столкнуться. Неужели нечем поделиться-похвастаться?

  • 29 октября 2010 в 08:10 • #
    Рахимжан Султанкулов

    Вениамин. Извини, но я тоже не оправдаю твоих надежд.
    Я советский глав. спец. а потом ГИП-стажер на самом излете. Хочу поумничать.
    Задача, решаемая в рамках проекта разовая. Как рисование картины маслом. Использование ТР экономит время и уберегает от многих ошибок предшественников. Только не следует класть на спину коровы седло. Процесс это последовательность рутинных действий. Управление проектами - это процесс. Считаю, что ИТ важнейший элемент управления проектами, но не главный. На память приходит хвост у ящерицы, бегающей по воде.
    В управлении проектами важна тщательность планирования и управляемость. Это как кладка кирпичной стены в первый раз. Если вы обнаруживаете дефект в укладке кирпича рядов эдак на 2-3, вы можете разобрать и заменить. А если рядов на 20? Пример для строителя ужасный, а для бизнес - технолога банка – сойдет.

  • 29 октября 2010 в 09:07 • #
    Вениамин Балашов

    Приветствую, Вас, Рахимжан!
    И согласен с Вами, и не согласен. Использование типовых решений - это плюс, если они наработаны самой компанией, через серию про-ошибок-осознания. Использование типовых внешних решений зачастую как раз и превращается в надевании седла на корову. Я, к сожалению, крайне мало встречал примеров осознанного разбора внешнего ТР для принятия решения о том, что из него можно вычленить для использования здесь и сейчас.
    В высшей степени согласен с тем, что тщательность планирования - это базис.

  • 21 декабря 2011 в 16:30 • #
    Вячеслав Шабанов

    Ребята: Вениамин, Геннадий и Рахимжан.
    ПримерИть ваши позиции можно лишь на основе, ранее упомянутого мною, АНС
    ANSI/PMI 99-001–2004 «Руководство к Своду знаний по управлению проектами» при
    условии тщательного его изучения и, самое главное, правильного понимания сущности методо-логии.
    В своей учебно-консалтинговой деятельности (более 20-ти лет), я многократно убеждался в том, что
    между ЗНАНИЕМ и ПОНИМАНИЕМ, как говорят в Одессе: «ДВЕ БОЛЬШИЕ РАЗНИЦЫ» –
    можно очень о многом знать и, при этом мало, что понимать, и, тем более,
    ЧТО УМЕТЬ ДЕЛАТЬ.
    Как часто говорит М. Задорнов: «американцы – ну такие тупые», что документируют (модели-руют)
    КАЖДЫЙ СВОЙ ШАГ (даже самый простой).
    ТО, что для нас, САМО СОБОЙ РАЗУМЕЕТСЯ – для них ЭТО СУЩНОСТЬ, которая подлежит
    РАССМОТРЕНИЮ с ЦЕЛЬЮ ОПТИМИЗАЦИИ ЕЕ ЖИЗНЕННОГО ЦИКЛА.
    Поэтому мы создали некоторое множество тупиковых направлений развития чего-либо, а
    Они множество методологий, технологий, стандартов и соответствующих CASE-средств.
    В качестве примера можно привести нашу «Единую систему конструкторской документации (ЕСКД)» –
    (см. семейство ГОСТ ЕСКД), а они – SADT, которая породила целое семейство международно-признанных
    CALS стандартов, без которых не была бы возможна УСПЕШНАЯ РЕАЛИЗАЦИЯ
    советско-американского космического проекта «СОЮЗ–АППОЛОН»
    (см. В США отмечают 30 лет проекта Союз-Апполон).

  • 29 октября 2010 в 10:57 • #
    Геннадий Чернецов

    До - было очень бедное планирование. После - планы в MS Project, включая оборудованное место менеджера проекта. До - не управляли рисками, проблемами, изменениями, документами, отчетами по проекту. Никто не следил за продвижением проекта. Мониторили события исключительно на совещаниях. После - менеджер проекта от завода и менеджер от строителей заполняли статусы задач, справочники проблем, рисков, изменений. Из Москвы в реальном масштабе времени выявлялись задержанные задачи и т.д. Характерно, что 17 менеджеров считали, что они работают, а система показывала 132 задержанных задачи, народ как мог прятал проблемы или тащил их к директору. Не хватало культуры управления проектом и у членов команды и у завода в целом. Мощная система управления проектами не вписывалась в старую культуру.

  • 29 октября 2010 в 11:02 • #
    Геннадий Чернецов

    Болячка была одна - проект, запущенный в январе значительно отставал от графика. Меня пригласили в мае. До конца проекта оставалось 6 месяцев. Сделали два действия. Поставили систему (А2) и сделали полное перепланирование проекта на основе инструментов проектного менеджмента. Немного поучили строителей, после чего я предложил по ряду объектов создать агрессивные планы (Решение Теории Ограничений). Провели обучение начальника стройки, заставили их приобрести интернет. Принятые агрессивные планы были выгружены в систему и начали контролироваться из Москвы. Результат - основные объекты через 3 месяца вышли на установленные сроки. Но и сейчас я отмечаю бездарное планирование работ по объекту со стороны строителей.

  • 31 октября 2010 в 22:00 • #
    Вениамин Балашов

    Вот, появились, все-таки, первые отзывы "До-После"!
    Поскольку тема все-таки глобальная, понятно, что в коротких сообщения крайне сложно уместить все, что хочется.
    Геннадий, как я понял, ключевая проблема "До" - отсутствие системы планирования, т.е. не только в подготовке планов, но в их администрировании. Вот тоько непонятно, зачем внедрять еще одну платформу (А2) при наличии Ms Project, да еще на разовый проект? Но это детали. Основные вопросы:
    - проект (как я понял) строительный, какая методика оценки имониторинга выполненных работ при этом применялась. Вопрос в том, что Ms Project и ему подобные не позволяют работать с физобъемами (крайне необходимая вещь для сторительных проектов), работа с расписанием (диаграмма Ганта) и оценка работ по выполненным затратам несовсем информативна и корректна. Как методически осуществлялся процесс планирования и учета выполненных работ?
    - каковы были изменения в области оргструктуры, бизнеспроцессов, документопотоках, мотивации?

  • 2 ноября 2010 в 23:00 • #
    Вениамин Балашов

    Ну что, видимо, кроме представителей консалтинга (лиц, прямо зарабатывающих на этой теме) обратной связи никто не предложет. Видимо причина в том, что действительно осознанного заказа от "предмета преобразований" крайне мало на просторах нашей "необъятной...". Это подтверждает меня в мысли, к которой я эволюционно пришел, занимаясь долгое время организационными преобразованиями, что действительно результативным может быть деятельность в части обсуждаемой нами темы только тогда, когда заказчик-топ/миддл менеджер может самостоятельно идентифицировать проблему и поставить соответствующую задачу (прописать пилюлю). А кто будет исполнять эту задачу, внутрення структура или внешние консультанты, не суть важно. Т.е. если подняться еще на один уровень, то можно сделать вывод, что перед тем, как человека выдвигают на управленческие позиции, его необходимо "насытить" знаниями в области управления (т.е. на его профессиональные компетенции наложить знание управленческих технологий). В этом случае уровень коммерциализации будет несколько ниже, соответственно, количество отзывов от потребителей будет выше. Как Вам такая позиция?

  • 28 июля 2014 в 11:59 • #
    Сергей Татаринов

    Очень с Вами согласен, Вениамин! Все, что до этого прочитал - голый консалтинг и самореклама (извините, коллеги!).
    Если первый руководитель: а) шикарный специалист в технологии, того, что производит, но посредственный управленец, не потративший достаточно времени на собственную управленческую компетентность; б) и полагает, что кто-то за него осуществит изменение (я - плачу, вы - работайте!); в) общий уровень управленческой компетентности ключевых руководителей системы (заместителей, начальников отделов и т.п.) недостаточен - хоть тресни, ничего не будет! Ни коня, ни шашки!
    Примеры: имею чудесный опыт реорганизации работы Отдела снабжения строительного холдинга, который вел строительство удаленных объектов с плечом до 500 км. Начальник отдела - мальчик со средним специальным образованием (техникум), персонал - 4 человека на побегушках. Но начальник закусил. По вечерам учился у меня факультативно (затем, кстати, закончил курс на профессиональный сертификат Школы бизнеса OU). Половину отдела выгнали, набор осуществляли уже под новую функциональную модель. Автоматизацию провели под модуль "1С:Управление снабжением". Результат: через полгода отдел в 5 человек очень результативно обеспечивал процесс материально-технического снабжения 5 удаленных объектов СМР (плечо от 270 до 500 км)!!!
    Другой пример: организация в 70 человек, узкоспециализированный подрядчик в строительстве, объем задач каждой службы (да того же снабжения) - мизерный. Идеальный вариант для проекта внедрения автоматизированной системы управления строительным предприятием! Типовое решение по автоматизации, кстати очень хорошего качества для небольшой организации - бери и работай. Директор сам напросился, по рекомендации предыдущего заказчика. Мол - очень хочу. Хороший парень, 34 года, образование - Академия бизнеса. Год в пустую. Причина - сам директор. Он, как бы все понимает и все ему НАДО, но ... не сегодня. Сегодня он всегда в текучке, трубку из уха не вынимает, переговорить некогда (в этот момент обязательно звонит заказчик, подрядчик или господь бог). Человек всегда бежит. На ходу принимая решения, которые завтра же на ходу отменяет. Все вокруг также суетно бегают, подражая. Персонал под его чутким руководством обеспечивает текучесть кадров примерно в 100%. Таким образом организация каждый новый день по уровню обученности оказывается дальше, чем была вчера. И весь управленческий персонал ему уже сменил, и ПО доработали и переработали под их проблемы несколько раз, и учили, и лечили - все как вода в песок.. "Святее папы римского быть нельзя".
    Дал себе слово - вижу в следующий раз такой уровень реальной готовности руководителя к изменениям и соответствующий уровень управленческой компетентности - не берусь ни за какие деньги!

  • 19 ноября 2010 в 19:00 • #
    Анастасия Занегина

    Настоящий менеджер проекта - это такая эпическая фигура с кнутом в правой руке, пряником в левой и оголенным навазелиненным тылом.

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

  • 20 ноября 2010 в 18:06 • #
    Вениамин Балашов

    И так бывает:) И часто:)

  • 20 ноября 2010 в 16:33 • #
    Олег Юрков

    Могу только поделиться из опыта работы в металлургической отрасли.
    1). По первому вопросу. Имеет ли электронное письмо в Вашей организации такую же силу как и бумажка? Т.е. имеется ли система типа Lotus? Графики в MSProject. База знаний так и осталась в папочках на диске :(
    2). По второму вопросу.
    Решение о старте проекта принимается на ИК, назначается РП и утверждается рабочая группа, оговаривается уровень суммы при которой РП может самостоятельно принимать решения, изменения в сроках или бюджете проекта оговаривается на ИК (реально тормозит проект, но если проектный офис слабо развит - обязательно). Организационная структура у нас представляла следующее: ИК, Нач.упр.проектами, Руководитель проектов, Аналитик, Менеджеры проектов (центральный офис, каждый ведет свой завод), менеджеры проектов (произв.площадки).
    3). Мотивация. Высокий уровень зарплаты, обучение и бонусы привязанные к графикам проектов.
    4). Белая каска и гаечный ключ ну и чуть-чуть дипломатии ;)
    5). Раз прописали на уровне отдал-взял-кто-где-кому-когда бамажку и дальше придерживались
    6). MSProject+Excel для многомиллионных проектов в металлургии вполне хватало...долго обучали заводских

  • 20 ноября 2010 в 18:22 • #
    Вениамин Балашов

    Вот, наконец-то!
    1. Все-таки приравняли электронное письмо к бумажному? Как в этом случае осуществлялось "согласование-визирование"? Графиков в Ms Project без возможности отражения физобъемов было достаточно - т.е. их использование в качестве расписания хватало? Как осуществлялись процессы пересмотра графиков? Метод учета исполнения? База знаний "в папочках" на дисках - возможно, если использовать унифицированную для всех проектов структуру папок.
    2. Здесь понятно, такие структуры видел/строил.
    3. Принцип распределения доходов в зависимости от вклада? Как определялся этот вклад? Критерии?
    4. Т.е. не было, условно, "Положения о рабочих группах" с подразделом о порядке решения конфликтных ситуаций?
    5. Понятно. Кто отвечал за взаимоувязку документов? Или самоорганизация?
    6. Понятно, какие отчеты использовались и для кого?

  • 21 ноября 2010 в 16:40 • #
    Олег Юрков

    :) ага...а то смотрю тебе только рекламу ИТ-шники кидают
    поставьте мою систему и пейте кофе...она все сделает за Вас :) вот ни разу не видел 100% работающей темы
    теперь по пунктам:
    1. Да. Lotus позволяет визировать в эл.виде и плюс всю переписку четко хранит в БД, к которой доступ только по паШпорту :)
    MSProject использовался только как временной график и отражение затрат по этапам работ (подробное расписание работ=стоимость было в Excele)
    Если изменения в графике не выходили за Х день (утвержденная дата окончания проекта), то это согласовывалось на уровне Нач.управления и менеджеров, а если менялись сроки окончания проекта или бюджет, то это только через ИК (раз в месяц, проекты были длительностью от 12 до 24 месяцев)
    Контроль за выполнением графика выполнялся по: информация по платежам за выполненные работы; еженедельное посещение пром.площадки; ежедневный созвон с пром.площадкой; эл.почтой в виде графиков.
    База знаний - хранилась у Руководителя проектов.
    2. ну Вы поняли
    3. Все банальней. Проектная структура была утверждена, всем были расписаны оклады. Процент премии тоже. А дальше за месяц до, расписывался лист достигаемых результатов и в зависимости от него уже Нач.управления распределял % премии.
    4. Конфликты возникали в 99 случаях между службами пром.площадки, а там лучший метод "белая каска+гаечный ключ". Все работало и опережало графики.
    5. За этим следили в основном Менеджеры проектов (центральный офис), так как с нас за это спрашивали.
    6. MSProject - график проекта план/факт.
    Excel - движения оплат по проекту, подробный перечень работ и материалов.
    PowerPoint - презентации для ИК

  • 23 ноября 2010 в 22:09 • #
    Вениамин Балашов

    Было бы полезно узнать о:
    - смысл внедрения, т.е. какую проблему пытались решить;
    - была ли решена эта проблема;
    - какие новые проблемы замаячили на горизонте в связи с нововведениями.
    Еще раз спасибо за участие в теме?
    А что, больше некому ничего интересного рассказать из реальной практики?

  • 25 ноября 2010 в 13:27 • #
    Олег Юрков

    1. Какую проблему пытались решить? Проблему успешного внедрения инвестиционных проектов на промышленных площадках Компании (четыре трубопрокатных завода).
    2. Вышеописанным проблема была решена и проекты внедрялись в сроки и в бюджете.
    3. Новые проблемы? Высокий уровень износа человеческих ресурсов и кое-где дублирование функций. В связи с этим были наняты МакКензи для разработки оптимальной схемы проектного офиса Компании. Результат - внедряется.

  • 22 ноября 2010 в 10:11 • #
    Ольга Неклеса

    По оптимизации бизнес-процессов в строительстве слышала хорошие отзывы об этой компании http://www.ibcon.ru/.
    Подрастем и тоже к ним обратимся.

  • 24 ноября 2010 в 23:29 • #
    Вениамин Балашов

    А сами никак? Зачем к кому-то обращаться?

  • 26 ноября 2010 в 15:46 • #
    Ольга Неклеса

    В сутках только 24 часа.

  • 26 ноября 2010 в 22:43 • #
    Вениамин Балашов

    Соотношение "затраты-результат". Предлагаю использовать данный ресурс для получения бесплатного трезультата.

  • 23 ноября 2010 в 10:48 • #
    Геннадий Чернецов

    А вот, думаю, интересный вопрос. Какая потребность удовлетворяется, когда предприятие вообще не собирается улучшать свою систему управления проектами (как это имеет место быть на ряде предприятий .....отрасли А, Б. С, Д)?

  • 23 ноября 2010 в 22:04 • #
    Вениамин Балашов

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

  • 23 ноября 2010 в 22:14 • #
    Геннадий Чернецов

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

  • 23 ноября 2010 в 22:15 • #
    Геннадий Чернецов

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

  • 24 ноября 2010 в 23:20 • #
    Вениамин Балашов

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

  • 24 ноября 2010 в 23:25 • #
    Вениамин Балашов

    Кроме этого, Геннадий, я готов поучаствовать в обсуждении темы, заданной Вами, но в другой ветке, т.к. цель этой - обмен мнениями о реальных результатах внедрения проектного управления.

  • 25 ноября 2010 в 09:16 • #
    Геннадий Чернецов

    Буду писать только о результатах внедрения проектного управления. Договорились.

  • 26 ноября 2010 в 22:45 • #
    Вениамин Балашов

    Спасибо. Создавайте параллельную ветку, пообщаемся.

  • 26 ноября 2010 в 22:52 • #
    Геннадий Чернецов

    Да попробую.

  • 20 декабря 2010 в 01:14 • #
    Алексей Ярцев

    Добрый день.

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

    Особенности бизнеса:
    - невысокая длительность проектов (3-5 месяцев), что определяет высокую плотность проекта во времени
    - достаточно типовые модели проектов (можно с достаточной четкостью определить стадии проектов)
    - высокая плотность проектов (в месяц до 30 проектов параллельно)
    - возможность увеличения (привлечения) ресурсов при увеличении количества проектов

    Данные особенности не ограничивают применимость "способа ведения проектов" (не говорю слова "методика" специально)

    Решавшиеся задачи:
    - коммуникация между участниками проекта
    - обеспечение хранения документов в единой структурированной базе с ролевым доступом
    - четкое распределение ответственности между участниками проекта на различных стадиях (этапах)проекта
    - отслеживание контрольных точек
    - создание единой картины пакета проектов

    Это базовый список. Дополнительные задачи, решавшиеся в некоторых компаниях:

    - Учет затрат на проекты вертикально (по подразделениям) и горизонтально (попроектно)
    - Расчет заработной платы и бонусных частей проектов
    - Взаимодействие со складами материалов и арендными складами
    - Ряд других специфических задач (учет затрат на автотранспорт, например, и т.д.)
    - Обеспечение взаимодействия географически удаленных офисов и подразделений компаний (решено через использование Интернет)
    - Работа с клиентской базой (базой заказчиков)

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

    Я не зря сказал ранее об особенности бизнеса: "возможность увеличения (привлечения) ресурсов при увеличении количества проектов". Эта особенность определяет подход к управлению проектами, смещая акценты с более детального планирования на оптимизацию затрат. Если у компании спрос на её услуги (может быть внешний, а может и внутренний при реализации собственных проектов - не важно) превышает ресурсное предложение (ресурсные возможности), то первоочередная задач стоит в детальном планировании ресурсов и четком отслеживании использования этих ресурсов для оптимизации рисков.

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

    Практически указанные ране задачи были решены созданием информационной системы с достаточно простой идеологией, в общих чертах выглядевшей следующим образом:

    - каждый проект разбивается на этапы
    - этап включает в себя некоторое количество документов (по сути, любое действие в проекте может порождать/завершаться документом, который может быть абсолютно любым - от Excel таблицы до видеоролика)
    - у каждого этапа есть ответственное лицо и несколько дедлайнов (даты "предупреждения" и "паники" - первая, когда загорается "лампочка", говорящая, что на этап надо обратить внимание, вторая - когда нужно применять "управляющее воздействие")
    - у каждого этапа есть понятие "виза" (или "подпись"), которую ставит ответственное за этап лицо, когда все документы по данному этапу собраны и загружены в систему
    - все проекты отображаются на едином календаре с цветовой индикацией просроченных этапов (сразу видно, с каким проектом проблема, на каком этапе и кто за это отвечает)

    При этом в системе может быть создано любое количество шаблонов этапов с проектами и документами, что позволяет фактически любой бизнес-процесс с достаточной степенью линейности превратить в шаблон проекта, что и было сделано, когда созданная система без изменений з

  • 23 декабря 2011 в 09:39 • #
    Александр Козлов

    Коллеги, всем доброго времени суток!
    К сожалени, поздно присоединяюсь в теме, поэтому, возможно, в некоторых вопросах повторюсь...
    Мне видится следующие ключевые аспекты внедрения:
    1. Эффективность, т.е. нужно вначале себе ответить на вопросы "чего ради" и "какой ценой"?
    Ведь экономическая эффективность собственно проектного управления "формально" не подтверждена. Существуют лишь зарубежные "лучшие практики", где эффективность достигает 20-30%. Но в откатной/ручной системе при объеме отката от 15%, как вы сами понимаете, затраты на СУП никогда не окупятся, да и риски внедрения высоки.
    2. "Портфельность" -- внедрить систему для единичного проекта и накладно и рискованно. Затраты могут окупиться лишь в случае очень крупного проекта, а ведь нужно еще и организационные процессы поменять...
    3. Сложность Системы управления Портфелем -- здесь речь идет именно о системной сложности и необходимости взаимосогласованного развития всех эементов (процессы, регламентирующий базис, оргстуктура, инфраструктура, обучение, и проч.).
    4. Квалификация -- к сожалению, в этой сфере слишком много профанаций.
    Вот... как-то так. Возможно, кто-то видит еще аспекты, которые могут оказать ключевое влияние...
    Я по этим вопросам изложил свое видение в серии книжек, рекомендую:
    http://www.pmpractice.ru/catalog/detail.php?ELEMENT_ID=1020
    http://www.pmpractice.ru/catalog/detail.php?ELEMENT_ID=1213

  • 25 декабря 2011 в 11:09 • #
    Вячеслав Шабанов

    Александр, привет.
    Спасибо за принятие моего приглашения с целью установления партнерских отношений и,
    для их начала, попробую ответить на все вопросы, которые Вы сформулировали, как
    с Вашей точки зрения, наиболее важные.
    1. Эффективность проектного управления. Прежде, чем ответить на вопрос:
    Какова эффективность проектного управления?
    Необходимо определить, что мы будем понимать под термином «эффективность управления».
    Эффективность (результативность) является отношением результата (эффекта) и затрат.
    Эффект может оказаться положительным, если результат приближается к
    идеальному состоянию, удовлетворяет целевую функцию, т.е. достижение определенной
    ЦЕЛИ реализации проекта и соответствует системе неизбежных ограничений (финансовых,
    ресурсных, включая кадровых, и т.п.).
    Но он может оказаться и отрицательным, если не удается выбранными средствами достичь
    установленной цели или удается, но невозможно при этом в полной мере соблюсти систему
    требуемых ограничений.
    Меру достижения ЦЕЛИ(-ей) можно оценить по определенным для каждого конкретного
    проекта показателям и параметрам.
    Что касается затрат, то при использовании SADT и соответствующего CASE-средства –
    BPwin с целью создания прикладной функционально/процессной модели (ПФПМ), то в
    каждом блоке на диаграммах процессов на всех этапах реализации конкретного проекта,
    предусмотрено определение необходимых затрат для выполнения каждой конкретной работы.
    Стоимость реализации проекта будет равна суммарной стоимости выполнения всех работ,
    которую можно минимизировать посредством ABC анализа созданной ПФПМ.
    2. «Портфельность» реализации проектов также достаточно просто можно обеспечить
    путем создания базовой (Б) ФПМ на основе опыта успешного использования нескольких
    ПФПМ ранее выполненных проектов и т.о. свести к минимуму все возможные риски.
    Пример БФМ «ВЫПОЛНИТЬ ПРОЕКТ» (ВП) можно посмотреть и «Скачать» по ссылке:
    http://www.freelancejob.ru/users/qm-it.master.shs/portfolio/86354/
    На основе этой БФМ было создано более 10-и ПФПМ успешной реализации
    ПРОЕКТОВ в различных (малых и больших) организациях и корпорациях в разных сферах
    учебной и/или научно-технической деятельности и отраслях экономики, например, при
    выполнении различных НИОКР.
    Примечание. На всех блоках диаграмм БФМ ВП в левом нижнем углу имеется обозначение
    «0р.» – это место для вписания стоимости выполнения каждой отдельной функции (работы) и
    проекта (любого процесса) в целом на TOP диаграмме (см. контекстную диаграмму А-0).
    3. Сложность Системы управления Портфелем также можно существенно снизить, если
    пойти по пути создания, введения в действие и непрерывного улучшения
    СИСТЕМЫ МЕНЕДЖМЕНТА ЗНАНИЙ (СМЗ), в которой возможно интегрировать и
    систематизировать:
    - прикладные знания участников команды проекта и участников реализации процессов на
    всех этапах жизненного цикла проекта в организации заказчика,
    - Свод знаний международно-признанных методологий, технологий и стандартов в
    областях TQM CALS IT, а также
    другие необходимые знания в области деятельности организации.
    Свое видение корпоративной СМЗ я представил на странице моего блога:
    https://professionali.ru/Link/Away/?link=http%3A//spooo.ru/blogs/user/qm-master-shs
    4. Квалификацию участников проекта можно существенно повысить, посредством
    проведения мастер класса в процессе реализации каждого конкретного проекта в
    каждой конкретной организации по согласованной программе обучения и
    проведения необходимых тренингов для достижения
    ЦЕЛИ ПРОЕКТА(-ОВ).
    Ответы на любые другие вопросы можно получить, используя
    БФМ «РЕШИТЬ ОПРЕДЕЛЕННУЮ ПРОБЛЕМУ(-Ы) В СМЗ», которая
    может быть направлена всем участникам ПАРТНЕРСКОЙ ПРОГРАММЫ
    «Путеводитель в мир TQM CALS IT», информация, о которой представлена на странице:
    https://professionali.ru/Link/Away/?link=http%3A//spooo.ru/blogs/user/qm-master-shs
    Более подробно свое видение решения возникающих проблем изложено в статье
    «Как получить гарантированные преимущества в конкурентной борьбе?
    или
    Повышение эффективности производства – «что делать?» и «как делать?»
    на ВЗГЛЯД ПРОФЕССИОНАЛА со стороны» конференции
    Современное понимание оптими

  • 24 декабря 2011 в 17:48 • #
    Сергей Павлов

    Думаю что к применению (или не применению можно к бухгалтерии просто топорно) MSProject, Lotus и более простые есть ещё одна доработка, именно для контроля выполненных работ и их качества на отдельных, отдаленных участках.Применялась и можно отзывы организовать. Но это уже область - консультационная.
    - - -
    последний комент, дипломатично, но честно, так устроены у нач дела, вносит коррективы в вашу возможность внедрения - по финансированию - внедрения.
    От себя могу вскрыть (не консультативно) 1. что стереотипы старой "культуры" с отсутсвием Культуры, как действующего фактора - вырисовался в данном обсуждении полно, хотя сервисность его очевидна.
    2. вы должны учитывать и разную качественную ценность профессионалов, обычно определяемую словом - компетентность, но это неполно, действующий в бизнесе собственная фабрика ковров в США, профессор униыерситета штата Огайо финансы, дал когда-то 7 способностей необходимых для успешного ведения дела как и 7 недостатков человеческих ведущих к банкротству.
    Всем благодарен за ценную и качественную информацию.

  • 25 декабря 2011 в 17:00 • #
    Сергей Павлов

    Слабым звеном всегда является коммуникация между реальным-практическим проектом, происходящим не только во времени но и в пространстве и его теоретическим планом в EPR.
    Привязка к месту и оперативное введение статусов исполнения и контроль качества.
    Как известно это прождало переорганизацию, вольный или не вольный саботаж и как следствие нарастающий отрыв реалий проекта от теории плана. Атмосферу неразберихи и порой и очковтирательства.
    Эти технологии позволяют сократить время и трудоёмкость контрольных операций до такого минимума, что ввод статусов хода проекта можно осуществлять практически в реальном времени прямо с места исполнения работ. Даже в удалённых местах. Даже с плохим интернет покрытием и сетью.
    Привязка контрольных операций не только к времени, но и к реальному месту технически гарантирует качество контроля качества и хода проекта ответственными лицами.
    По ходу проекта каждый ответственный в зависимости от своей функции в проекте знает не только что и когда, но и что когда и где (для него непосредственно здесь) нужно делать, или должно быть проконтролировано / сделано.
    В рамках сотрудничества с концернами БАСФ АГ и Бильфингер АГ
    Генеральная инспекция в Лойна (Французский концерн) в 2007 году.
    3000 человек от 150 подрядчиков, 25 000 Запчастей. Стройка стоила порядка 200 миллионов евро, была детально спланирована, посчитана, и продлилась ровно 51 день.
    Раффинери Миро прокачивает через себя 16 мил.тонн нефтепродуктов в год.
    Совместно используется BP, Shell, Esso и ConocoPhilips.
    Самая большая рафинери в Германии. 200 человек должны за три месяца провести инспекцию и ремонт 350 установок. Колонн, Ёмкостей, Факелов, Охладителей.
    Благодаря нашей программе концерн Бильфингер получил большой заказ на три "остановки" – инспекции Миро 2010, 2012, 2014.

    Всех С Новым годом!
    Желаю Крепчайшего Здоровья! Успеха! Всех Благ!

  • 2 апреля 2012 в 14:03 • #
    Борис Хакимов

    Подскажите, как осуществить контроль качества? Где об этом можно прочитать?

    С уважением.

  • 9 июня 2012 в 16:14 • #
    Вячеслав Шабанов

    Здравствуйте Борис.
    Прежде чем осуществлять контроль качества необходимо задать критерии качества разработки и/или
    производства продукции и/или предоставления услуг на всех этапах их жизненного цикла, определить
    контрольные точки в контролируемом процессе(-ах) и контрольные операции, выполняемые
    службой качества, если таковая имеется в организации/на предприятии.
    Все эти процедуры и многие другие принципы, методы, технологии и международные или национальные стандарты
    (МС или НС) составляют область знаний, которая называется
    ВСЕОБЩЕЕ УПРАВЛЕНИЕ КАЧЕСТВОМ (TQM), которая включает
    СИСТЕМУ МЕНЕДЖМЕНТА КАЧЕСТВА (СМК) организации.
    Для начала ознакомления с СМК наберите в поисковой строке, например, Яндекса текст:
    «система менеджмента качества это» и Вы выйдете на множество публикаций по этой теме.
    А как СМК практически создается и вводится в эксплуатацию, можно посмотреть на
    моих страницах сайта по адресам:
    http://spooo.ru/post/article/6495 и
    http://spooo.ru/offer/item/198
    С уважением, Вячеслав.

  • 11 июня 2012 в 08:09 • #
    Борис Хакимов

    Спасибо, Вячеслав!

  • 22 января 2012 в 16:33 • #
    Владимир Благодырёв

    ЗДРАВСТВУЙТЕ ВЕНИАМИН!
    То ,что Вас интересует,практически освоено на частном производственно-строительном комбинате,расположенного в г.Мелитополь , при внедрении в практику строительства (построены,сданы в эксплуатацию около 40 Объетов в киевской,запорожской областях,Республике КРЫМ и в г, Севастополе общей площадью около 100тыс.М2) новой инновационной конструктивной технологии :СИСТЕМА СБОРНО-МОНОЛИТНЫЙ КАРКАС УНИВЕРСАЛЬНЫЙ БЕЗРИГНЛЬНЫЙ (аналог -российская СИСТЕМА КУБ-2.5 КАРКАС УНИФИЦИРОВАННЫЙ БЕЗРИГЕЛЬНЫЙ) правда в "полуавтоматическом" режиме по причине отсутствия заказчиков Объектов.
    На комбинате внедрена система управления технологическим процессом в полном производственном цикле в соответствии с ИСО 9001 В 2008 году(проектирование ,изготовление,доставка и монтаж конструкций на расстоянии до700км от комбината).


Выберите из списка
2019
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008