Показано с 1 по 30 из 36
-
26.03.2007, 18:49 #1
- Регистрация
- 16.04.2006
- Сообщений
- 151
Разработка бизнес-процессов
Уважаемые дамы и господа, посоветуйте с чего начать описание и разработку бизнес-процессов для повышения управляемости и контроля отдела?
Я делал всё по методическим материалам: описывал "as is" далее "to be". Но такая каша получалась. И как внедрить потом это всё?
Поделитесь опытом, пожалуйста.
-
01.05.2007, 13:03 #2
- Регистрация
- 21.12.2005
- Сообщений
- 19
Интересная статья по теме
На этом сайте есть интересная статья по теме...
http://www.cfin.ru/itm/bpr/work_proc...heduling.shtml
-
01.05.2007, 17:33 #3
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Dias, существует мнение (Елиферов и Репин, цитирую по памяти, могу что-то упустить), что описывать As is не очень полезно:
1. Увеличивается количество информации,
2. При описании to be могут потеряться важные идеи, которые были,
3. И может отбиться у людей желание наконец что-то улучшать.
Подразумевается внедрение через разработку и регламентацию процессов, их согласование (в том числе входов/выходов), затем доработку, разработку рабочих инструкций, утверждение. Затем уже обучение персонала и сбор статистики, возможно, доработка регламентов.
По своему опыту (с IT-шным уклоном), могу сказать вот чего. На "как есть" я трачу очень немного времени, одно краткое поверхностное интервью, не более того (это чаще всего политический момент, "создание локомотива", на котором потом "выезжать" проекту). После того, как выяснено "что нужно", и, собственно, разработки, идёт внедрение, а именно, те же самые обучение, и применение со сбором статистики, возможно, доработка продукта.
-
01.05.2007, 19:15 #4
- Регистрация
- 12.05.2006
- Сообщений
- 2,180
Начинать надо "от яйца":
- какие цели, задачи, функции отдела
- какие результаты, риски, задачи и механизмы внутреннего контроля
....
Может так статься, что на корню изменять бизнес-процессы и нет необходимости. Достаточно подгрузить Петю, чтобы он контролировал Васю, Васю контролем Оли, Олю контролем Пети - а самому проверять подтверждения осуществления каждым из них функций контроля за своим соседом.
Это называется segregation of duties.
-
02.05.2007, 11:38 #5
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Каша
Сообщение от Dias
Что-то не так в консерватории: либо функции отдела слабо формализованы, либо у отдела нет собственных функций (т.е. он только участвует в сквозных процессах компании). В обоих случаях стоит серьезно задуматься - в том числе и о целях анализа.
-
02.05.2007, 11:43 #6
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от Andruxa
При описанном вами подходе получается не внедрение, а подгонка компании под предлагаемый вами продукт. Хорошо, если продукт подходит, а если нет?
-
02.05.2007, 12:10 #7
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Сообщение от Александр Болдин
-
02.05.2007, 13:06 #8
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от Andruxa
-
07.05.2007, 11:07 #9
One, статья абсолютно стандартная, ничего интересного там нет. Andruxa, IT последний этап, это первое. Вопрос был в другом, это второе. Genn, согласна. У меня лично это реализовано. Экономист по учету доходов контролирует работу менеджера по выписке первички и старшего кассира. Экономист по закупам - склад. Dias, могу посоветовать только взять бумагу, ручку. Нарисовать схему отдела и разрисовать подчиненность и взаимозаменяемость. Потом положение об отделе, должностные инструкции, положения о ведении отдельных операций (о кассовых операциях, о финансовой документации, о проведении инвентаризаций и проч.). Я дополнительно на переходной период ввела систему планирования загрузки на месяц. Удобно контролировать и сотрудники знают, что делать.
-
07.05.2007, 12:48 #10
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Да, я начал отвечать на вторую часть вопроса, больше чем на первую - именно про внедрение. Выделение процессов - это именно "разгадывание" (может даже и с элементами интуитивного) процессов. Есть рекомендации. Конкретизируйте, какая у вас там "каша" получилась.
(Что-то у вас интерес пропал. текучки насыпалось?)
Dias, рекомендую опять же Елиферов, Репин, их книгу. У них первая глава - как раз по поводу, как выделять процессы. Вторая - как управлять. Третья - как описывать. Четвертая - как их все увязать (и внедрять). Вот первая глава и четвертая - будут полезны.
-
07.05.2007, 13:13 #11
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от Andruxa
Давайте оставим "выделение процессов" консультантам, порхающим над процессами компаний на высоте птичьего полета, и кидающим с этой высоты советы пирожникам на основе опыта внедрения у сапожников.
-
07.05.2007, 13:26 #12
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Сообщение от Александр Болдин
например: рекомендуется выделять по границам функциональных подразделений, процесс не должен выходить за ЦФО, д.б. не менее, чем создание определенного продукта, имеющего ценность и т.д.
На самом деле, не стоит забывать, что под процессом понимается система мероприятий по созданию некоторого продукта (выхода) из входа с привлечением ресурсов (они всегда есть, осознаны они или нет). Все это измеряется, пусть даже что-то интервально, регламентируется, и управляется.
Как минимум, результатом описания и внедрения, становится управляемая система бизнес-процессов.
p.s. я не консультант вообще-то. просто приходится иногда пользоваться такими "консультантскими" инструментами при внедрении ПО.
-
07.05.2007, 13:55 #13
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от Andruxa
Кстати книга получилась очень хитрая - по отзывам можно понять насколько поверхностно ее читали. Если читать по диагонали - складывается впечатление, что авторы предлагают выделять процессы по подразделениям и так далее - то есть оргструктура рулит. Но если читать вдумчиво, а потом еще позадавать вопросы кому-то из авторов (один из них является постоянным участником этого форума), выясняется что нужно границы подразделений выстраивать в рамках происходящих в компании процессов. И опираться надо на процессы, а не оргструктуру.
Оставляю за собой право на собственное мнение - здесь для меня было важно указать на неточность.
-
07.05.2007, 14:07 #14
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Сообщение от Александр Болдин
если хотите обсудить книгу и моё её понимание - давайте поговорим в той ветке, которую открыл я в реинжиниринге.
-
07.05.2007, 14:18 #15
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от Andruxa
Других таких книг все равно пока нет: одним некогда, у других есть время, но их читать без спецподготовки - себе дороже.
-
07.05.2007, 14:33 #16
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
К сожалению - это о том, что уточнение ваше мимо кассы, если оно было адресовано лично мне. я не столько в бесплатных оценках своей "подготовки" нуждаюсь, сколько в "роскоши человеческого общения" по существу.
А книга и действительно отличная.
Тоже хочу автограф.
-
07.05.2007, 14:40 #17
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от Andruxa
Если "по существу", это уже не роскошь, а мега-роскошь человеческого общения. Какой-то Куршавель
-
14.05.2007, 12:25 #18
- Регистрация
- 16.04.2006
- Сообщений
- 151
Описание процессов под ПО - с этим всё ясно более менее.
А вот описание и анализ процесса (т.е. анализ с целью дальнейшего изменения), с этим уже сложнее. Мне как-то тоже посоветовали не писать "как есть", а сразу - "как должно быть", чтобы избежать тягомотины с анализом и выявлением всяких там причин.
Что касается оргструктуры - если высшее звено управления находится вне процессов, то можете вообще ничего не описывать. Вся картина строится на конечном управленческом решении, которое влияет на тот или иной процесс. И когда руководитель говорит - опиши этот процесс, но меня не включай, то это не подход, а элементарный уход от всего. А дальше больше - за руководителем последуют менеджеры, за менеджерами сотрудники. В результате есть процесс на бумаге - нет в реале.
-
14.05.2007, 12:26 #19
- Регистрация
- 16.04.2006
- Сообщений
- 151
Сообщение от Andruxa
-
15.05.2007, 13:55 #20
- Регистрация
- 16.04.2006
- Сообщений
- 151
Такой вопрос: какой инструментарий сейчас популярен для моделирования бизнес-процессов?
-
15.05.2007, 14:10 #21
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от Dias
Это - первая тройка. Она не меняется довольно давно.
Есть еще перспективный отечественный инструмент Business Studio.
В его раскрутку в России кто-то вкладывает неслабые деньги... по крайней мере топ-менеджеров уже заинтересовали.
-
15.05.2007, 17:21 #22
- Регистрация
- 16.04.2006
- Сообщений
- 151
Сообщение от Александр Болдин
-
15.05.2007, 17:30 #23
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от Dias
По всем вопросам надо обращаться в компанию ФОРС (www.fdc.ru) - они являются партнерами CASEWISE у нас.
-
16.05.2007, 10:13 #24
- Регистрация
- 19.12.2005
- Сообщений
- 1,108
В конце мая в компании FORS состоится открытый и бесплатный семинар по CaseWise 1/2 дня. Дата пока не определена, где-то между 28-31 мая.
CaseWise тоже, конечно, не идеальное ПО для описания БП, но идеология построения у него более подходящая для этих целей.
С уважением Виталий.
-
16.05.2007, 12:18 #25
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Про идеальные инструменты вообще речь не идет - разобраться бы с необходимым функционалом.
На мой взгляд, темам выбора нотаций и инструментов для моделирования процессов уделяется слишком большое внимание. Как со стороны продавцов программного обеспечения (что логично), так и со стороны менеджмента компаний (что непонятно). Ну не имеет эта тема такого значения в ряду жизненно важных вопросов фирмы.
Могу навскидку назвать более важные темы: например разграничение по функционалу и полномочиям между корпоративным центром и бизнес-единицами.
Без решения этой и аналогичных проблем моделирование бизнес-процессов превращается в "игры разума". Все бы хорошо, но во-первых прямые и косвенные потери от этих игр наносят существенный удар по бюджету, а во-вторых заявленная неадекватная модель надолго блокирует попытки правильного подхода.
-
16.05.2007, 12:32 #26
- Регистрация
- 19.12.2005
- Сообщений
- 1,108
О хитрой книжке...
Еще раз перечитал свои книжки и не нашел в них категорических фраз с содержанием: "процесс=подразделению".
1-я книга R&E "Процессный подход к управлению. ..." - есть фразы:
- " принимать во внимание оргструктуру ..." ; " очень часто Процесс не ограничивается рамками одного подразделения..." - (написано было в 2001-2002 г.г. sic!)
2-я книга E&R "Бизнес-процессы. ..." - есть фразы: "Конечно процесс не равен подразделению...", " мы не проводим знак равенства "подразделение"="процесс". (написано в 2003-2004 г.г.)
Это фразы видны даже при чтении "по диагонали".
Не знаю: по какой параболе, эвольвенте или кохлеоиде нужно читать, чтобы увидеть смысл, который авторы не вкладывали?
С уважением Елиферов Виталий (соавтор R&E и E&R).
-
16.05.2007, 12:39 #27
- Регистрация
- 21.02.2007
- Сообщений
- 2,056
Сообщение от eliferov
прошу прощения, но вы ориентировались на пересказ моих слов Александром, а не на мои. я могу говорить про выделение процессов по границам структурных подразделений как рекомендуемое, и все связанные с этим плюсы и минусы (знак равенства и я не ставил, и понимание вашего подхода у меня есть) я не упомянул в этой ветке не для того, чтобы дать повод к дискуссии, а лишь ввиду того, что не счел необходимым в рамках совета "почитать книгу".
А вообще, я имел ввиду первую главу книги "Бизнес-процессы: управление и регламентация".
с уважением, Андрей.
-
16.05.2007, 13:01 #28
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от Andruxa
Может быть, вы имели в виду что-то еще - я не в курсе. Я же ж не Вольф Мессинг.
По существу вопроса:
Мы можем получить информацию о процессах компании двумя способами:
1. Пройти назад по цепочке создания стоимости от продажи продукта клиенту до создания этого продукта.
2. Рассмотреть сервисы, которые подразделения оказывают внешним и внутренним контрагентам.
В первом случае мы получим "продуктово-процессную модель", во втором "структурно-процессную". Не судите строго - названия условные, придуманы только что.
Проблема в том, что при создании системы управления на базе процессного подхода мы вынуждены использовать одновременно оба типа моделей. Стараясь по возможности их интегрировать.
Отсюда и проистекают вот такие идеологические трудности. Где выход?
И тут я не скажу ничего нового: нужно начинать с соглашения о моделировании (регламента формирования процессной модели ... есть и другие названия).
Документ должен быть простым и однозначно воспринимаемым всеми участниками проекта. Не стоит вливать в него копи-пастом обширные куски из стандартов моделирования, как это часто делают (у меня сейчас лежит как раз такой проект регламента - ужос). Короткого описания целей и методов их достижения вполне достаточно.
-
16.05.2007, 13:14 #29
- Регистрация
- 25.11.2005
- Сообщений
- 690
Сообщение от Александр Болдин
А "продуктивная цепочка" звучит хорошо.
Александр, а эти модельеры дают какие-нибудь рекомендации по качеству моделей пользователей? Есть ли какой-нибудь анализ графа процессов?
-
16.05.2007, 14:16 #30
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от Сахават
Какие-то средства проверки связности модели есть практически везде. Но даже в этом случае их трудно применять - не всегда понятно ошибка это или "так и было задумано". Пока что процесс моделирования процессов слабо формализован ... несмотря на наличие кучи стандартов.