Страница 2 из 2 ПерваяПервая 12
Показано с 31 по 36 из 36
  1. #31
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    210

    По умолчанию

    Цитата Сообщение от Александр Болдин
    Мы можем получить информацию о процессах компании двумя способами:
    1. Пройти назад по цепочке создания стоимости от продажи продукта клиенту до создания этого продукта.
    2. Рассмотреть сервисы, которые подразделения оказывают внешним и внутренним контрагентам.

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

    Отсюда и проистекают вот такие идеологические трудности. Где выход?
    Далее Александр приводит ответ, который хотелось бы дополнить следующим соображением. Отчасти определить центр тяжести этих компонент и сбалансировать их по объему использования в построении модели позволяет маркетинговый подход. А именно определение эластичности спроса на выпускаемую продукцию: неэластичный - ориентация на продукт, эластичный - на сервисы для клиента.

  2. #32
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от GRIG
    Отчасти определить центр тяжести этих компонент и сбалансировать их по объему использования в построении модели позволяет маркетинговый подход.
    Мое отношение к Маркетингу (с большой буквы) озвучено в другой ветке форума. Не хочу ругаться - замнем для ясности?
    Цитата Сообщение от GRIG
    А именно определение эластичности спроса на выпускаемую продукцию: неэластичный - ориентация на продукт, эластичный - на сервисы для клиента.
    1. Эластичность по чему?
    2. А если продукт это и есть сервисы для клиента? Пример - телекоммуникационные компании.

  3. #33
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию To Andruxa ...

    я так понимаю, пост мне адресован?
    Не только Вам. Очень многие, из читавших книги, видят, почему-то, только "процесс=подразделение".

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

  4. #34

    По умолчанию Описание бизнес процессов.

    Уважаемый Dias

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

    Что значит повышение управляемости? Управление - это достижение определенных целей, поставленных перед управленцем. "Повышение управляемости" - что Вы имели в виду? Улучшения статистики достижения целей?

    Но улучшения статистики достижения цели можно достигать другими методами. Например, изменением системы мотивации. То есть сильнее поощрять сотрудников за то, что они достигнут цели. Или наказывать сильнее, за то, что не достигли. У Вас работает управленческий цикл по отношению к сотрудникам? Проводятся регулярные аттестации, проводится постановка и оценка достигнутых целей? Может быть Вам надо сначала аттестацию наладить?

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

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

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

    Во вторых, если все не так плохо, и описанные выше инструменты (и другие похожие) уже применены, действуют, и речь идет действительно о тонкой настройке.

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

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

    Обычно методологии разрабатывают консатинговые компании - это и есть их основной продукт. Иногда эти методологии попадают в книги - правда в достаточно упрощенном варианте.

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

    В частности, Финэкспер, свою какую то методологию имет, которую пропагандирует. Компания ПОРЯДОК также свою методологию проектирования имеет, более подробная информация на сайте www.modellab.ru

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

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

    Всего... vbmenu_register("postmenu_70365", true);
    Последний раз редактировалось Невольниченко Елена; 25.05.2007 в 15:12.

  5. #35
    Член сообщества
    Регистрация
    24.05.2007
    Сообщений
    171

    По умолчанию Еще одно дополнение к теме

    Уважаемый Dias, пусть с опозданием, но все-таки хотела бы добавить несколько строк к обсуждению Вашего вопроса. Вот несколько моих практических наблюдений (надеюсь, они будут полезны в работе над Вашим проектом):
    1. Каша в описании может получится из-за нечеткого определения цели моделирования. Описать абсолютно все с учетом всех аспектов и точек зрения на процесс невозможно, поэтому приходится накладывать определенные ограничения и выделять значимые и незначимые вещи для описания. И здесь как раз приходится ориентироваться на цель моделирования (подготовка регламентирующих документов, автоматизация процесса, его оптимизация и т.п.). Например, с т.з. автоматизации процесса акцент делается на движении информации, при оптимизации – на выявлении проблемных зон, а при подготовке регламентов нужно максимально подробное описание и взгляд с т.з. исполнителя процесса (т.к. ему потом по этим регламентам работать). Кстати, цели определяют и выбор нотации моделирования и программного продукта.
    2. При описании очень важно знать меру! Очень часто возникает соблазн двух видов: а) максимально детализироваться – вплоть до «нажатия кнопочки», а это может быть и не нужно, но сильно усложнит и запутает модель; б) бесконечно совершенствоваться, особенно в модели to be. У меня есть печальный опыт, когда эксперты на протяжении двух (!) лет заставляли переписывать описание одних и тех же процессов и бесконечно согласовывали подготовленные документы, меняя там то по 1-2 слову, то в корне переделывая весь процесс. Результат соответствующий. Умейте вовремя остановиться!
    3. При внедрении самое сложное пробить сопротивление персонала и добиться, чтобы процесс действительно заработал по-новому, а не остался на бумаге. И здесь полностью согласна с Andrux’ой – обучение, обучение и еще раз обучение. Важно донести до людей, зачем им это надо, так что опять упираемся в цели моделирования.

  6. #36
    Новый участник
    Регистрация
    06.06.2007
    Сообщений
    1

    По умолчанию

    Цитата Сообщение от Олешко Виктория
    Уважаемый Dias, пусть с опозданием, но все-таки хотела бы добавить несколько строк к обсуждению Вашего вопроса. Вот несколько моих практических наблюдений (надеюсь, они будут полезны в работе над Вашим проектом):
    1. Каша в описании может получится из-за нечеткого определения цели моделирования. Описать абсолютно все с учетом всех аспектов и точек зрения на процесс невозможно, поэтому приходится накладывать определенные ограничения и выделять значимые и незначимые вещи для описания. И здесь как раз приходится ориентироваться на цель моделирования (подготовка регламентирующих документов, автоматизация процесса, его оптимизация и т.п.). Например, с т.з. автоматизации процесса акцент делается на движении информации, при оптимизации – на выявлении проблемных зон, а при подготовке регламентов нужно максимально подробное описание и взгляд с т.з. исполнителя процесса (т.к. ему потом по этим регламентам работать). Кстати, цели определяют и выбор нотации моделирования и программного продукта.
    2. При описании очень важно знать меру! Очень часто возникает соблазн двух видов: а) максимально детализироваться – вплоть до «нажатия кнопочки», а это может быть и не нужно, но сильно усложнит и запутает модель; б) бесконечно совершенствоваться, особенно в модели to be. У меня есть печальный опыт, когда эксперты на протяжении двух (!) лет заставляли переписывать описание одних и тех же процессов и бесконечно согласовывали подготовленные документы, меняя там то по 1-2 слову, то в корне переделывая весь процесс. Результат соответствующий. Умейте вовремя остановиться!
    3. При внедрении самое сложное пробить сопротивление персонала и добиться, чтобы процесс действительно заработал по-новому, а не остался на бумаге. И здесь полностью согласна с Andrux’ой – обучение, обучение и еще раз обучение. Важно донести до людей, зачем им это надо, так что опять упираемся в цели моделирования.
    Добрый день, я недавно на этом форуме, может, что-то из прошлых тем не знаю, но могу сказать, что взаимодействие с персоналом один из наиболее важных фактов, потому как если люди не понимают, то для них любой процесс будет каша. С сопротивлением сталкиваюсь постоянно, самое худшее, когда персонал устраивает «итальянскую» забастовку. Особенно когда в подразделении есть не явный лидер, которому вообще все новое не по-душе и он начинает дискредитировать проект, таща за собой других. Так как стадный рефлекс развит лучше, чем стремление к совершенству. Плюс присоединяюсь к тому, что излишнее описание не есть хорошо, принцип избыточности тут не подходе, всего не учтешь.
    Возможно, я повторяю ранее сказанное, но персонал это больная тема всех проектов.

Страница 2 из 2 ПерваяПервая 12

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •