15 января 2009 в 14:28

Внедрение BMP

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

781
Комментарии (42)
  • 15 января 2009 в 14:34 • #
    Дмитрий Березин

    Андрей, я не совсем понял какого совета вы хотите?

  • 15 января 2009 в 14:39 • #
    Андрей Зырянкин

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

  • 15 января 2009 в 14:37 • #
    Людмила Гераськова- Isaev

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

  • 15 января 2009 в 14:44 • #
    Андрей Зырянкин

    Данная проблема возникла не на пустом месте, а после внедрения САПР. Денег дали, а низы не захотели. Сейчас все в ожидании - а я крайний.
    Сейчас назревает новый прект - Управление бизнес-процессами

  • 15 января 2009 в 15:21 • #
    Владимир Шелухин

    Странно: а кто у низов спрашивает? (Это если исходить из того, что новая САПР пригодна для использования по назначению).
    Что значит — против? Против получать зарплату в офисе? Так можно получать пособие на бирже. Или против криво внедрённой и так же документированной системы?

  • 15 января 2009 в 14:43 • #
    Анастасия Мещерякова

    конкретизируйте пожалуйста ваш вопрос,
    С уважением,
    Анастасия Мещерякова

  • 15 января 2009 в 14:46 • #
    Андрей Зырянкин

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

  • 15 января 2009 в 14:52 • #
    Андрей Зырянкин

    У Вас же есть опыт начала создания проектов (я не подрячик, внедрения внутри компаний) и Вы понимаете что создание бизнес-плана и описательная часть - это время. Не хочется тратить время зря. Все смотрят на ИТ.

  • 15 января 2009 в 15:06 • #
    Анастасия Мещерякова

    Андрей, предлагаю обменяться информацией по e-mail: #
    Мой опыт в таких ситуациях начиная с 1996г (1С,EFAS, SAP, Axapta)

  • 15 января 2009 в 15:08 • #
    Сергей Владимирович Семекашев

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

  • 15 января 2009 в 16:04 • #
    Андрей Зырянкин

    Да ВЫ правы есть решения и надо внедрять для бизнеса
    Экономическая эффиктивность - оценить трудно, если будет саботаж хорошо хоть выйти на положительный результат

  • 16 января 2009 в 11:45 • #
    Алексей Амельченко

    ЭФ - это стартовая позиция. Она не должна быть "труднооцениваемой". Это раз.
    А два - попробуйте сделать 2 разных подхода: для верхов, отталкиваясь от отдачи и прибыли, для низов - от удобства и комфорта.

  • 15 января 2009 в 15:20 • #
    Андрей Зырянкин

    Да ВЫ правы есть решения и надо внедрять для бизнеса

  • 15 января 2009 в 15:22 • #
    Victor Filippov

    Добрый день, Андрей
    Мне кажется, что одназначно необходимо в первую очередь получить поддержку ответственных лиц, в Вашем случае, как я понимаю, это владельцы бизнеса.
    Для них пишется Концепция Проекта. В рамках Концепции предлагаете примерный состав Рабочей группы.
    После ее принятия, создается издается приказы об Открытии проекта и переходу к фазе Планирование, создании Рабочей группы Проекта, в которую войдут, в том числе, представители Потребителя Продукта Проекта.

  • 15 января 2009 в 15:30 • #
    Андрей Зырянкин

    Предлагаете соблюсти методологию руководства РМ ВОК

    Чесно говоря я об этом думал, только как наказывать кто не справляется

  • 15 января 2009 в 16:02 • #
    Victor Filippov

    Предлагаете соблюсти методологию руководства РМ ВОК
    .........
    ))))
    Уставы пишутся кровью.
    Надо всячески стараться учится на чужих ошибках.
    ---------------------------------------

    как наказывать кто не справляется
    .........
    Ваш вопрос очень важен!
    Вы не задумывались, а почему они не справляются?
    ----------------------------------------

    В рамках Приказа о создании Рабочей группы разрабатывается и определяется Система Мотивации Команды Проекта.

  • 15 января 2009 в 16:05 • #
    Андрей Зырянкин

    Да я пытаюсь сейчас понять чужие ошибки.
    Почему они не справляются? Как сказал мне один руководитель при внедрении САПР - а зачем что то новое мы и так деньги приносим.
    При этом ни кто не смотрит на конкуренцию и будущее.

  • 15 января 2009 в 16:08 • #
    Victor Filippov

    ))))
    Уставы пишутся кровью.
    Надо всячески стараться учится на чужих ошибках.

    да

  • 15 января 2009 в 16:09 • #
    Андрей Зырянкин

    Да я пытаюсь сейчас понять чужие ошибки.
    Почему они не справляются? Как сказал мне один руководитель при внедрении САПР - а зачем что то новое мы и так деньги приносим.
    При этом ни кто не смотрит на конкуренцию и будущее.

  • 15 января 2009 в 16:11 • #
    Victor Filippov

    не очень хорошо Вас понимаю.

    Приказ есть? есть.
    Система мотивации разработана? разработана.
    Менеджер проекта подписался - подписался.
    Рабочая группа ознакомлена - ознакомлена.
    Не справляются - мотивируйте, стимулируйте, меняйте в конце концов.

  • 15 января 2009 в 16:10 • #
    Victor Filippov

    иной альтернативы нет.

    "Ищем спеца, который знает предметную область или специалиста в проектном управлении"
    один мой хороший знакомый

  • 15 января 2009 в 16:19 • #
    Андрей Зырянкин

    делема, надо думать - меняйте - в моей компании это уволить.
    Потеря взаимо отношений с сотрудниками, возможно.

  • 15 января 2009 в 16:42 • #
    Victor Filippov

    опишите проблему подробнее, что смогу - подскажу.

  • 15 января 2009 в 22:38 • #
    Николай Матюхин

    Андрей, просветите пожалуйста :)

    Что такое BMP ?

    Building Material Planning ?
    BitMaP - формат растровых изображений ?
    Быть может не ВМР, а ВРМ - Волоконно-Распределительный Модуль ?

    Ответ мне не дала даже википедия.
    А предложение участвовать в дискуссии пришло на почту 2 раза :)

    Надеюсь вас не затруднит расшифровать аббревиатуру.

    С уважением,
    Николай.

  • 16 января 2009 в 09:37 • #
    Анастасия Мещерякова

    управление эффективность бизнес - процессов

  • 16 января 2009 в 21:31 • #
    Николай Матюхин

    Спасибо :)

  • 16 января 2009 в 11:17 • #
    Андрей Зырянкин

    BPM(Business Process Management, Управление бизнес-процессами, некоторые добавляют Моделирование и Мониторинг к общему термину)

  • 16 января 2009 в 21:31 • #
    Николай Матюхин

    Спасибо :)

  • 16 января 2009 в 09:41 • #
    Анастасия Мещерякова

    Короче, сначала представляем высшему руководству ПРОЕКТ создания КИС на базе...
    Этот документ должен содержать:
    - Назначение создания КИС
    - Логические рамки проекта
    - Этапы внедрения системы САПР
    - План проекта по внедрению системы в Группе Компаний
    и много что потом!

  • 16 января 2009 в 10:34 • #
    Victor Filippov

    Под Проектом Вы понимаете некий Документ?

    Фазы жизненного цикла Проекта:

    Концепция
    Разработка (Планирование)
    Реализация
    Завершение

    Указанные Вами документы появляются в конце Фазы Разработка (Планирование)

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

  • 16 января 2009 в 11:00 • #
    Анастасия Мещерякова

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

  • 16 января 2009 в 12:13 • #
    Victor Filippov

    (На предидущем месте работы я занимал должность руководителя Проектного Офиса.)

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

    И только после принятия Концепции, приступать к фазе Планирования. Занимаясь Организацией Проекта и создавая рабочую группу, в которую войдут представители Окружения проекта, в том числе представители Инвестора (Руководства?), Подрядчика и Заказчика. Включая их в команду Проекта, мы так же снимаем будущие потенциальные конфликты. Окружение проекта хорошо будут знать что, для чего и зачем.

  • 16 января 2009 в 12:36 • #
    Анастасия Мещерякова

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

  • 16 января 2009 в 12:48 • #
    Victor Filippov

    Анастасия
    нам надо разработать общий глоссарий, возможно мы говорим об одном и том же. )))

    То, что вы называете "ПРОЕКТ (презентацию) регламент по управлению проектом" возможно скорее всего является Концепцией проекта, в случае, если в документе "ПРОЕКТ (презентацию)" раскрывается вопрос актуализации проекта для организации.
    И в этом случае - с Вами полностью соглашусь

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

  • 16 января 2009 в 15:17 • #
    Анастасия Мещерякова

    Виктор
    на моей практики реализации проектов были случаи когда концепцию писал сам Заказчик или когда ИТ система запущена в эксплуатацию, и спустя 1-2 мес внедренцы переписывали концепцию.
    Сначала я хотела написать, что мы говорим об одном и том же(концепция). Но потом поняла, что вот он риск (верхи - не знают, низы - не хотят, не могут, саботируют).
    Концепция - это документ ИТ решений, в кот Исполнитель пишет как он понял поставленную задачу по бизнес- процессам каждого топ-менеджера Заказчика. Осуществляется АНАЛИЗ текущей деятельности и предложения, как может быть в системе функционировать бизнес - процесс потом. В результате на фазе разработки(планирование) появляются документы кот Вы уже описали.
    НО, покажите мне хоть одного руководителя Высшего звена, кот будет смотреть Концепцию - документ на 150-200 стр описаний + схемы БП в ARIS, PPT и т.д., описание требований по функциональной части + топология проекта.
    Виктор, думаю нам надо договориться не о глоссарии, а о том, что надо разделять проекты управленческие и проект внедрения ИТ - решений. Это во-первых.
    Относительно роли инициатора - РИСК по проекту. Это во-вторых.
    В дальнейшем, руководство может просто проститься с Инициатором.
    Руководить проектом должен менеджер, кот имеет опыт внедрения комплексных проектов, построение КИС в холдингах, кот знает как применить PMBoK, знает схемы мотивации, знает процессы поддержки и осуществление техподдержки пользователей,
    знает процессы управления изменениями в ИТ системе, управление проблемами, кот умеет строить команду проекта - описывает роли участников проекта и т.д.
    Осуществлять фазу реализации проекта должен - ИТ директор, помогает группа консультантов проектного офиса, сам руководитель проекта.

  • 16 января 2009 в 16:21 • #
    Victor Filippov

    Все таки глоссарий )))
    (корпоративные особенности Положений о Проектном Формате)

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

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

    Надеюсь, наша дискуссия принесет пользу автору ветки и поможет ему в его профессиональонй деятельности.

  • 16 января 2009 в 16:29 • #
    Анастасия Мещерякова

    Взаимно.
    С уважением,
    Анастасия Мещерякова
    e-mail: #

  • 16 января 2009 в 11:03 • #
    Анастасия Мещерякова

    я прекрасно это понимаю

  • 16 января 2009 в 12:13 • #
    Victor Filippov

    Нисколько не сомневаюсь

  • 16 января 2009 в 12:37 • #
    Анастасия Мещерякова

    Виктор - Вы в Москве, а я в Питере. Далее вы сами .......смотря на участников конференции.
    Спасибо

  • 16 января 2009 в 20:29 • #
    Артём Лупанин

    Добрый день. Любое внедрение начинается с ВЕРХА компании. Основными достоинствами внедрения BPM является:

    1.Прозрачность процесса
    2.Оперативная отчетность
    3.Сокращение трудозатрат , за счет автоматизации и оптимизации
    4.Оперативное изменение логики системы, в условиях конкуренции и изменения законодательства
    5.Сокращения времемени обслуживания клиента или выполнения работ внутри предприятия (логистика, разработка услуг)

  • 16 января 2009 в 20:39 • #
    Артём Лупанин

    И конечно же очень важный момент - лояльность пользователей и подходы внедрения.

    Мои рекомендации по внедрению BPM проектов:
    1.Заниматься автоматизацией бизнес-процессов совместно с Оптимизацией, невозможно автоматизировать Хаос. Если подходить так, то любой пользователь станет лояльным, однако это потребует некоторой экспертизы от интегратора в части сферы деятельности заказчика
    2. Использовать agile подход и многократные тестовые релизы продукта


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