Разработка бизнес-процессов

[Dias]

Уважаемые дамы и господа, посоветуйте с чего начать описание и разработку бизнес-процессов для повышения управляемости и контроля отдела?
Я делал всё по методическим материалам: описывал "as is" далее "to be". Но такая каша получалась. И как внедрить потом это всё?
Поделитесь опытом, пожалуйста.

[One]

На этом сайте есть интересная статья по теме...
http://www.cfin.ru/itm/bpr/work_proc...heduling.shtml

[Andruxa]

Dias, существует мнение (Елиферов и Репин, цитирую по памяти, могу что-то упустить), что описывать As is не очень полезно:
1. Увеличивается количество информации,
2. При описании to be могут потеряться важные идеи, которые были,
3. И может отбиться у людей желание наконец что-то улучшать.

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

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

[Genn]

Начинать надо "от яйца":
- какие цели, задачи, функции отдела
- какие результаты, риски, задачи и механизмы внутреннего контроля
....
Может так статься, что на корню изменять бизнес-процессы и нет необходимости. Достаточно подгрузить Петю, чтобы он контролировал Васю, Васю контролем Оли, Олю контролем Пети - а самому проверять подтверждения осуществления каждым из них функций контроля за своим соседом.
Это называется segregation of duties.

[А.Б.]

Уважаемые дамы и господа, посоветуйте с чего начать описание и разработку бизнес-процессов для повышения управляемости и контроля отдела?
Я делал всё по методическим материалам: описывал "as is" далее "to be". Но такая каша получалась. И как внедрить потом это всё?

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

[А.Б.]

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

Или я что-то не так понял, или одно из двух...
При описанном вами подходе получается не внедрение, а подгонка компании под предлагаемый вами продукт. Хорошо, если продукт подходит, а если нет?

[Andruxa]

Или я что-то не так понял, или одно из двух...
При описанном вами подходе получается не внедрение, а подгонка компании под предлагаемый вами продукт. Хорошо, если продукт подходит, а если нет?

Теперь я ничего не понял. Что значит подгонка компании под продукт. Кратко спрашиваешь, как работают. Спрашиваешь, чего хотят. Обычно понятно, что "вот это хотим чтобы было автоматически, это хотим по кнопочке, а это показывать так". Продукт разрабывается уже после разборок, "что нужно". Естественно, при этом реорганизуются взаимосвязи и взаимодействие между подразделениями: один продукт дает выход нескольким подразделениям, они меняют не только содержание общения, но и порядок. И я говорил в основном об обучении, и хочу подчеркнуть кстати его важность. После него вся работа по-новому и начинается.

[А.Б.]

Теперь я ничего не понял.

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

[satca]

One, статья абсолютно стандартная, ничего интересного там нет. Andruxa, IT последний этап, это первое. Вопрос был в другом, это второе. Genn, согласна. У меня лично это реализовано. Экономист по учету доходов контролирует работу менеджера по выписке первички и старшего кассира. Экономист по закупам - склад. Dias, могу посоветовать только взять бумагу, ручку. Нарисовать схему отдела и разрисовать подчиненность и взаимозаменяемость. Потом положение об отделе, должностные инструкции, положения о ведении отдельных операций (о кассовых операциях, о финансовой документации, о проведении инвентаризаций и проч.). Я дополнительно на переходной период ввела систему планирования загрузки на месяц. Удобно контролировать и сотрудники знают, что делать.

[Andruxa]

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

Dias, рекомендую опять же Елиферов, Репин, их книгу. У них первая глава - как раз по поводу, как выделять процессы. Вторая - как управлять. Третья - как описывать. Четвертая - как их все увязать (и внедрять). Вот первая глава и четвертая - будут полезны.

[А.Б.]

Выделение процессов - это именно "разгадывание" (может даже и с элементами интуитивного) процессов.

Вот поэтому я и возражаю все время против "выделения процессов". Мало того, что от "выделений" хорошего не жди (8~)), так еще за ними сразу приходит "разгадывание".
Давайте оставим "выделение процессов" консультантам, порхающим над процессами компаний на высоте птичьего полета, и кидающим с этой высоты советы пирожникам на основе опыта внедрения у сапожников.

[Andruxa]

Вот поэтому я и возражаю все время против "выделения процессов". Мало того, что от "выделений" хорошего не жди (8~)), так еще за ними сразу приходит "разгадывание".
Давайте оставим "выделение процессов" консультантам, порхающим над процессами компаний на высоте птичьего полета, и кидающим с этой высоты советы пирожникам на основе опыта внедрения у сапожников.

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

p.s. я не консультант вообще-то. просто приходится иногда пользоваться такими "консультантскими" инструментами при внедрении ПО.

[А.Б.]

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

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

[Andruxa]

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

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

[А.Б.]

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

Почему "к сожалению"?
Других таких книг все равно пока нет: одним некогда, у других есть время, но их читать без спецподготовки - себе дороже.

[Andruxa]

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

[А.Б.]

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

А в платных? Я бесплатных оценок не даю. .. только намекаю.
Если "по существу", это уже не роскошь, а мега-роскошь человеческого общения. Какой-то Куршавель

[Dias]

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

[Dias]

Dias, рекомендую опять же Елиферов, Репин, их книгу. У них первая глава - как раз по поводу, как выделять процессы. Вторая - как управлять. Третья - как описывать. Четвертая - как их все увязать (и внедрять). Вот первая глава и четвертая - будут полезны.

Спасибо за совет.

[Dias]

Такой вопрос: какой инструментарий сейчас популярен для моделирования бизнес-процессов?

[А.Б.]

Такой вопрос: какой инструментарий сейчас популярен для моделирования бизнес-процессов?

ARIS, CASEWISE, BPWIN.
Это - первая тройка. Она не меняется довольно давно.

Есть еще перспективный отечественный инструмент Business Studio.
В его раскрутку в России кто-то вкладывает неслабые деньги... по крайней мере топ-менеджеров уже заинтересовали.

[Dias]

ARIS, CASEWISE, BPWIN.
Это - первая тройка. Она не меняется довольно давно.

Есть еще перспективный отечественный инструмент Business Studio.
В его раскрутку в России кто-то вкладывает неслабые деньги... по крайней мере топ-менеджеров уже заинтересовали.

Про CASEWISE не слышал. Надо прочитать про него.

[А.Б.]

Про CASEWISE не слышал. Надо прочитать про него.

А он в России представлен года два-три всего. Из пользователей могу навскидку назвать: МТС, Ростелеком, Минэкономразвития, Бауманка, Администрация Ханты-МАнсийского округа.
По всем вопросам надо обращаться в компанию ФОРС (www.fdc.ru) - они являются партнерами CASEWISE у нас.

[eliferov]

В конце мая в компании FORS состоится открытый и бесплатный семинар по CaseWise 1/2 дня. Дата пока не определена, где-то между 28-31 мая.
CaseWise тоже, конечно, не идеальное ПО для описания БП, но идеология построения у него более подходящая для этих целей.
С уважением Виталий.

[А.Б.]

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

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

[eliferov]

Еще раз перечитал свои книжки и не нашел в них категорических фраз с содержанием: "процесс=подразделению".
1-я книга R&E "Процессный подход к управлению. ..." - есть фразы:
- " принимать во внимание оргструктуру ..." ; " очень часто Процесс не ограничивается рамками одного подразделения..." - (написано было в 2001-2002 г.г. sic!)
2-я книга E&R "Бизнес-процессы. ..." - есть фразы: "Конечно процесс не равен подразделению...", " мы не проводим знак равенства "подразделение"="процесс". (написано в 2003-2004 г.г.)
Это фразы видны даже при чтении "по диагонали".
Не знаю: по какой параболе, эвольвенте или кохлеоиде нужно читать, чтобы увидеть смысл, который авторы не вкладывали?
С уважением Елиферов Виталий (соавтор R&E и E&R).

[Andruxa]

Еще раз перечитал свои книжки и не нашел в них категорических фраз с содержанием: "процесс=подразделению".
1-я книга R&E "Процессный подход к управлению. ..." - есть фразы:
- " принимать во внимание оргструктуру ..." ; " очень часто Процесс не ограничивается рамками одного подразделения..." - (написано было в 2001-2002 г.г. sic!)
2-я книга E&R "Бизнес-процессы. ..." - есть фразы: "Конечно процесс не равен подразделению...", " мы не проводим знак равенства "подразделение"="процесс". (написано в 2003-2004 г.г.)
Это фразы видны даже при чтении "по диагонали".
Не знаю: по какой параболе, эвольвенте или кохлеоиде нужно читать, чтобы увидеть смысл, который авторы не вкладывали?
С уважением Елиферов Виталий (соавтор R&E и E&R).

я так понимаю, пост мне адресован?

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

А вообще, я имел ввиду первую главу книги "Бизнес-процессы: управление и регламентация".

с уважением, Андрей.

[А.Б.]

прошу прощения, но вы ориентировались на пересказ моих слов Александром...

Перечитал обсуждение - слава богу оно небольшое. Не нашел, где бы я как-то интерпретировал ваши слова - везде сплошь цитаты.
Может быть, вы имели в виду что-то еще - я не в курсе. Я же ж не Вольф Мессинг.


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

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

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

[Сахават]

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

Скорее 2. просто второй этап (вспомогательные процессы).
А "продуктивная цепочка" звучит хорошо.

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

[А.Б.]

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

Вопрос конечно интересный :~)
Какие-то средства проверки связности модели есть практически везде. Но даже в этом случае их трудно применять - не всегда понятно ошибка это или "так и было задумано". Пока что процесс моделирования процессов слабо формализован ... несмотря на наличие кучи стандартов.