от AS IS к TO BE

[Kotic]

Уважаемые коллеги, решила разобраться в том, как происходит переход от модели AS IS к модели TO BE при реинжиниренге бизнес-процессов. Какие методы и средства истользуються??? Может есть рекомендации по тематической литературе...
Буду рада любой информации и ссылкам, даже англоязычным.
Заранее большое спасибо)

[Сергей А. Степанов]

Попробуйте начать отсюда:
http://en.wikipedia.org/wiki/Change_...t_(engineering)
http://en.wikipedia.org/wiki/Change_management_(people)

[А.Б.]

Чаще всего, когда вы (соместно с теми кто работает в процессе) смогли построить модель TO BE - задача перехода уже не стоит. Остается только закрепить изменения в каком-нибудь нормативном документе (приказе, регламенте и т.п.).
Глубочайшее заблуждение бизнес-аналитика - думать что ты знаешь что и как надо делать лучше, чем человек который этим занимается постоянно в течение нескольких лет. В лучшем случае, мы можем указать на какие-то системные ошибки или посоветовать новые технологии, про которые человек, потонувший в текучке, еще не знает.

[Константин Тютюнов]

Попробуйте начать отсюда:
http://en.wikipedia.org/wiki/Change_...t_(engineering)
http://en.wikipedia.org/wiki/Change_management_(people)

Поскольку указанные статьи отсутсвуют (неясно почему), то как понимаю, предлагается их написать

Можно взять указанные материалы на другом ресурсе:
http://www.powerset.com/explore/semh...nge+management
http://www.powerset.com/explore/semh...t_%28people%29

Вообще ресурс толковый, всем рекомендую.

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

[Константин Тютюнов]

как происходит переход от модели AS IS к модели TO BE при реинжиниренге бизнес-процессов

Как и советовали ранее имеет смысл копать летературу по управлению изменениями.
А по методам в голову приходят следующие:
- модель изменений групп и коллективов Курта Левина (разморозить, изменить, заморозить).
- цикл Деминга-Шухарта (планирование-выполнение-проверка-корректировка). В этом смысле полезно при внедрении новой модели несколько раз прокрутить данный цикл: на уровне анализа регламента/документа всеми стейкхолдерами, по итогам "тестового запуска" и по итогам "внедрения нового регламента в эксплуатацию". (Пространство доктора Деминга)
- "дерево перехода" и анализ "негативных веток" Голдратта.(Теория ограничений Голдратта)
- весь арсенал дисциплины управления проектами: управление интеграцией, содержанием, сроками, стимостью, качеством, рисками, персоналом, поставками и коммуникациями (Руководство к своду знаний по управлению проектами)

[Кручинецкий Сергей]

Чаще всего, когда вы (соместно с теми кто работает в процессе) смогли построить модель TO BE - задача перехода уже не стоит. Остается только закрепить изменения в каком-нибудь нормативном документе (приказе, регламенте и т.п.).
Глубочайшее заблуждение бизнес-аналитика - думать что ты знаешь что и как надо делать лучше, чем человек который этим занимается постоянно в течение нескольких лет. В лучшем случае, мы можем указать на какие-то системные ошибки или посоветовать новые технологии, про которые человек, потонувший в текучке, еще не знает.

Я так понял, что вопрос автора темы как раз в том и состоит, как перейти к модели TO BE. К сожалению, на практике задача внедрения новой редакции бизнес-процессов редко решается изданием приказа. Внедрение - это сложный процесс, для которого есть свои методики.
Ну а если "бизнес-аналитик" не знает, как сделать лучше на основании собственного опыта, лучше ему за оптимизацию б/п не браться.

[Евгений_Кс]

1. Реинжиниринг как коренная ломка процесса уже не в моде, однако. Хаммер и Чампи выскочили, шумнули и куда-то скрылись.
2. К толковому перечню Тютюнова добавлю еще восьмишаговую модель Дж.Коттера

[А.Б.]

1. Реинжиниринг как коренная ломка процесса уже не в моде, однако. Хаммер и Чампи выскочили, шумнули и куда-то скрылись.

Ну да. Пора возвращаться от языка попугайского к нормальному:

Инжиниринг процессов - услуги, предоставляемые специализированным подразделением или внешей компанией, по постановке в организации новых процессов или оптимизации действующих.
Реинжиниринг процессов - восстановление модели процесса в некоем стандарте по действующему процессу.

Ссылок не жди - это я сам придумал только что.

[Евгений_Кс]

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

Не так.
Инжиниринг процессов - услуги, предоставляемые Консультантом по постановке в организации новых процессов.
Реинжиниринг процессов - восстановление процесса в прежнем виде после ухода Консультанта.

[А.Б.]

Не так.
Инжиниринг процессов - услуги, предоставляемые Консультантом по постановке в организации новых процессов.
Реинжиниринг процессов - восстановление процесса в прежнем виде после ухода Консультанта.

Вот вам бы все шуточки.
А люди-то верят. Даже каких-то "внутренних консультантов" придумали - полный бред между прочим... или полный бренд ... кто его знает.
:-Р

[Kotic]

Всем огромное спасибо!!!
Много ценной информации, буду с ней работать )

[Bend]

...Даже каких-то "внутренних консультантов" придумали - полный бред между прочим... или полный бренд ... кто его знает.:-Р

Веяние времени...
А вообще, есть ли смысл во внутреннем консалтинговом отделе? Просто, без учета размера компании и сфер бизнеса...

[DrNeuron]

Чаще всего, когда вы (соместно с теми кто работает в процессе) смогли построить модель TO BE - задача перехода уже не стоит. Остается только закрепить изменения в каком-нибудь нормативном документе (приказе, регламенте и т.п.).
Глубочайшее заблуждение бизнес-аналитика - думать что ты знаешь что и как надо делать лучше, чем человек который этим занимается постоянно в течение нескольких лет. В лучшем случае, мы можем указать на какие-то системные ошибки или посоветовать новые технологии, про которые человек, потонувший в текучке, еще не знает.

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

[DrNeuron]

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

[А.Б.]

Веяние времени...
А вообще, есть ли смысл во внутреннем консалтинговом отделе? Просто, без учета размера компании и сфер бизнеса...

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

[Andruxa]

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

если именно описания, смотрите BPMN, и книгу Мишина "Проектный бизнес".

[А.Б.]

...

Невозможно выполнение БП - в том виде как вы его придумали, не сумев разобраться. Скорее всего, интервью было не с теми людьми. Или владельцем процесса назначен человек, который в нем ничего не понимает ... это случается сплошь и рядом. Часто именно этот БП (в этом департаменте и с этими людьми) не выполняется вообще и просто прилип как навоз к сапогу ... к реально выполняющейся в совсем другом месте работе.

Процессы предприятия - квантовые объекты. Здесь велико "влияние наблюдателя" - как только вы начинаете описывать процесс ... он тут же начинает меняться. Если описывать правильно и достаточно долго ... в конце описания это уже будет не AS IS, а TO BE ... или даже TOO BE.

[eliferov]

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

1. Если организация не достигла цели, то в 94% случаев - это вина руководства (упрощенная цитата из У.Е. Деминга).
2. Если консультант не достиг цели то в 94% - .... (См №1).
3. Как Вы описали "верхний уровень основных процессов" не зная, что "в компании нет элементарых инструментов управления ..."? На верхнем уровне главное - это управление и его инструменты.
4. Как Вы взялись за проект внедрения процессного подхода в организации где "... нет элементарых инструментов управлени ..."? Перед проектом надо проводить диагностику и отказываться, если организация не готова к такому уровню управления.
Провал консультанта для организации означает провал методики. Мне приходилось работать после чужих провалов, встречали словами:"Видали мы консультантов, вы у нас пятые (6, 7 и т.д.)". Мне это обходилось в лишний месяц трудозатрат (этот месяц добавлял в проект, но по результатам обследования).
С уважением Виталий.
P.S. Личная просьба: Уменьшите, пожалуйста, количество опечаток в тексте. Трудно читать.

[А.Б.]

>> ... я сделал все как надо (естественно мне надо)
Здесь собсно все.
Повторюсь:
Глубочайшее заблуждение бизнес-аналитика - думать что ты знаешь что и как надо делать лучше, чем человек который этим занимается постоянно в течение нескольких лет.

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

Too beer or not too beer
That is the question

[Polina]

Да никак не может бизнес-аналитик сам, на основе каких-нибудь мифических методологий, от "as is" к "to be" перейти. Но работать то как-то нужно. Поэтому, обычно 2 пути:
1. Если аналитик не очень опытный. Просто рисует "as is" со слов эксперта. Потом это ему показывает, обсуждает, можно ли это к лучшему изменить, смотрят они как эти изменения могут затронуть другие подразделения и рисует "to be", тоже со слов эксперта. Потом бегает по всем затронутым и согласовывет. В результате, какой-то общий консенсус вырисовывается. По крайней мере, сотрудники организации умеют теперь рисовать процессы и сами могут чего-то наваять при желании.
2. Если аналитик опытный. Особенно, если знаком с конкретной отраслью. Тоже бегает, рисует "as is", попутно выясняет где проблемы есть. Далее начинает использовать:

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