Показано с 31 по 36 из 36
-
16.05.2007, 14:32 #31Сообщение от Александр Болдин
-
16.05.2007, 14:41 #32
- Регистрация
- 24.11.2005
- Сообщений
- 3,432
Сообщение от GRIG
Сообщение от GRIG
2. А если продукт это и есть сервисы для клиента? Пример - телекоммуникационные компании.
-
16.05.2007, 18:03 #33
- Регистрация
- 19.12.2005
- Сообщений
- 1,108
To Andruxa ...
я так понимаю, пост мне адресован?
То Болдин
Тем более, за время прошедшее с ее выхода, кое-какие позиции авторов могли измениться.
С уважением Виталий.
-
25.05.2007, 13:29 #34
Описание бизнес процессов.
Уважаемый Dias
Во первых, цели, которые Вы обозначили (повышение управляемости, контроль) не факт, что должны достигаться описанием бизнес-процессов. Тем более в рамках одного подразделения.
Бизнес-процессы - это инструмент для устранения проблем прежде всего на стыках подразделений в организации.
Что значит повышение управляемости? Управление - это достижение определенных целей, поставленных перед управленцем. "Повышение управляемости" - что Вы имели в виду? Улучшения статистики достижения целей?
Но улучшения статистики достижения цели можно достигать другими методами. Например, изменением системы мотивации. То есть сильнее поощрять сотрудников за то, что они достигнут цели. Или наказывать сильнее, за то, что не достигли. У Вас работает управленческий цикл по отношению к сотрудникам? Проводятся регулярные аттестации, проводится постановка и оценка достигнутых целей? Может быть Вам надо сначала аттестацию наладить?
Что значит "улучшение контроля"? Контроль - это выявление не соответствия действий сотрудников установленным правилам и нормам. У Вас уже есть установленные правила и нормы? Они контролируются - то есть происходит регулярная проверка соответствия реальной работы правилам и нормам? Возможно Вам не бизнес-процессы надо описывать, а регулярную качественную процедуру аудита запустить.
Может быть вариант, когда у Вас работа вообще не описана - поэтому нечего контролировать. Тогда начните просто с описания работы людей, что они должны делать. Введите нормы - какое количество звонков, например, и начните это регулярно контролировать.
Можно точно говорить, что управление с использованием бизнес-процессов - это более тонкий инструмент, чем описанные выше, и результаты он дает, когда более грубые инструменты уже действует.
Во вторых, если все не так плохо, и описанные выше инструменты (и другие похожие) уже применены, действуют, и речь идет действительно о тонкой настройке.
Тогда совет следующий: для того, чтобы каши не получилось, нам для описания процессов надо выбрать и использовать одну методологию.
Тут есть засада. Обычно путают нотацию и методологию описания. Нотация - это некий язык моделирования, примерно то же самое что русский язык, или английский язык. Просто знать язык недостаточно, чтобы на нем уметь писать стихи. Так же и с нотацией. Недостаточно знать IDEF, чтобы уметь правильно выделить процессы на предприятии.
Обычно методологии разрабатывают консатинговые компании - это и есть их основной продукт. Иногда эти методологии попадают в книги - правда в достаточно упрощенном варианте.
В методологии содержится описание подходов, шагов, действий, которые необходимо сделать, чтобы получилось какое то стройное описание процессов, а не каша.
В частности, Финэкспер, свою какую то методологию имет, которую пропагандирует. Компания ПОРЯДОК также свою методологию проектирования имеет, более подробная информация на сайте www.modellab.ru
Так вот. Рекомендую следующее. Попытайтесь поскать методологии. Если найдете какую - попытайтесь провести описание четко следуя методологии, даже если в чем то с ней не согласны. Если получившийся результат Вас не удовлетворит - то возьмите другую, и сделайте описание точно по ней.
Вероятнее всего на второй-третей иттерации Вы поднатореете настолько, что начнете понимать, что Вам все таки нужно и в каком виде, чтобы решить свои проблемы.
Всего... vbmenu_register("postmenu_70365", true);Последний раз редактировалось Невольниченко Елена; 25.05.2007 в 15:12.
-
25.05.2007, 19:18 #35
Еще одно дополнение к теме
Уважаемый Dias, пусть с опозданием, но все-таки хотела бы добавить несколько строк к обсуждению Вашего вопроса. Вот несколько моих практических наблюдений (надеюсь, они будут полезны в работе над Вашим проектом):
1. Каша в описании может получится из-за нечеткого определения цели моделирования. Описать абсолютно все с учетом всех аспектов и точек зрения на процесс невозможно, поэтому приходится накладывать определенные ограничения и выделять значимые и незначимые вещи для описания. И здесь как раз приходится ориентироваться на цель моделирования (подготовка регламентирующих документов, автоматизация процесса, его оптимизация и т.п.). Например, с т.з. автоматизации процесса акцент делается на движении информации, при оптимизации – на выявлении проблемных зон, а при подготовке регламентов нужно максимально подробное описание и взгляд с т.з. исполнителя процесса (т.к. ему потом по этим регламентам работать). Кстати, цели определяют и выбор нотации моделирования и программного продукта.
2. При описании очень важно знать меру! Очень часто возникает соблазн двух видов: а) максимально детализироваться – вплоть до «нажатия кнопочки», а это может быть и не нужно, но сильно усложнит и запутает модель; б) бесконечно совершенствоваться, особенно в модели to be. У меня есть печальный опыт, когда эксперты на протяжении двух (!) лет заставляли переписывать описание одних и тех же процессов и бесконечно согласовывали подготовленные документы, меняя там то по 1-2 слову, то в корне переделывая весь процесс. Результат соответствующий. Умейте вовремя остановиться!
3. При внедрении самое сложное пробить сопротивление персонала и добиться, чтобы процесс действительно заработал по-новому, а не остался на бумаге. И здесь полностью согласна с Andrux’ой – обучение, обучение и еще раз обучение. Важно донести до людей, зачем им это надо, так что опять упираемся в цели моделирования.
-
06.06.2007, 11:23 #36
- Регистрация
- 06.06.2007
- Сообщений
- 1
Сообщение от Олешко Виктория
Возможно, я повторяю ранее сказанное, но персонал это больная тема всех проектов.