Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
А почему Вы реальность большинства компаний — притчей назвали?
В статье описана процедура Идентификации бизнес-процессов. И если по этому термину поискать, то материала наберётся достаточно для практического применения.
материала наберётся достаточно для практического применения.
Практическую методику, по которой можно было бы провести инвентаризацию и классифицировать процессы компании 500+, исключительно «для практического применения» — искал три года. Не нашел.
Инвентаризация таких объектов, «которых не видно» — совсем не простая штука. Во всяком случае, для крупной компании. Надеюсь, мы не путаем эти процессы с моделирование процессов.
Дайте тройку ссылок, желательно чтобы они были с примерами и не противоречили друг другу. Очень интересно.
Ссылки искать не буду, но на практике приходилось выгружать почти готовые карты БП из:
-Положения о подразделении
-Каталоги процессов контуров управления системы менеджмента качества или функционально стоимостного анализа
-Отраслевые каталоги процессов, стандарты группы компаний, источники референсных данных аналогичных компаний.
Так что для компаний 500+ иногда проще составить карту, поскольку кто-то и когда-то аналогичную работу уже проделывал.
-Положения о подразделении
-Каталоги процессов контуров управления системы менеджмента качества или функционально стоимостного анализа
-Отраслевые каталоги процессов, стандарты группы компаний, источники референсных данных аналогичных компаний.
Так что для компаний 500+ иногда проще составить карту, поскольку кто-то и когда-то аналогичную работу уже проделывал.
В целом с подходом согласен. Но:
«Положения о подразделении» — есть, но многое зависит от качества составления этих положений. Проанализировать все положения — не так то и просто.
СМК — скорее редкость, чем правило. Если идет упоминание о ИСО 9000 — то это, как правило, только «чистая формальность» (чтобы повесить на сайте «у нас ИСО 9000»).
Какие? Я упоминал о APQC Process Classification Framework (PCF). Что еще?
Про «референсных данных аналогичных компаний» — это же «военная тайна», все их (реестры процессов) скрывают (почему то).
«Положения о подразделении» — есть, но многое зависит от качества составления этих положений. Проанализировать все положения — не так то и просто.
СМК — скорее редкость, чем правило. Если идет упоминание о ИСО 9000 — то это, как правило, только «чистая формальность» (чтобы повесить на сайте «у нас ИСО 9000»).
Отраслевые каталоги процессов, стандарты группы компаний, источники референсных данных аналогичных компаний.
Какие? Я упоминал о APQC Process Classification Framework (PCF). Что еще?
Про «референсных данных аналогичных компаний» — это же «военная тайна», все их (реестры процессов) скрывают (почему то).
Мысли вслух: Когда на хабре наконец-то появится раздел «Управление процессами»?
Давать статью по BPM в разделе «Управление проектами» — это кощунство!
Давать статью по BPM в разделе «Управление проектами» — это кощунство!
А снизу идентифицировать процессы нельзя? тупо сесть рядом с сотрудником и смотреть, что же он делает, зачем, как ходят те или иные бумажки?
Да, «снизу идентифицировать» в ряде случаев можно, а иногда даже автоматически: «программа формирует верхний уровень процессов сама, полностью автоматически, беря за основу взаимодействия в процессах нижнего уровня.» (дал бы ссылку, но здесь запретили мне их делать).
Нужно понимать, что это возможно только для «малочисленных» процессов. Например, «наиболее известный классификатор бизнес-процессов» (упоминание о котором и ссылку мне также пришлось удалить) только на верхнем уровне содержит 1620 процессов.
Например, только один из процессов (из 1620 высокоуровневых) «8.1.2.5 Управление архитектурой предприятия» разбивается на огромное число более детальных бизнес-процессов.
Если идти «снизу» – как Вы предлагаете: от «самого детального» к верхнеуровневому, то можно идти «всю жизнь» даже для небольшой части процессов из «наиболее известного классификатора».
Т.е. для совсем небольшой задачи – да, можно идти снизу.
Но вот именно так: «тупо сесть рядом с сотрудником и смотреть, что же он делает, зачем, как ходят те или иные бумажки» — это только для совсем микроскопической задачи (небольшого процесса) или с огромным штатом BPM-работников, «тупо сидящих рядом».
Вообще, в ОДНОМ кросс-функциональном процессе задействовано (по определению) много сотрудников и несколько участвующих подразделений.
К тому же: при описании детальных процессов — досконально формализуется документооборот, что на верхнем уровне совсем не нужно.
Нужно понимать, что это возможно только для «малочисленных» процессов. Например, «наиболее известный классификатор бизнес-процессов» (упоминание о котором и ссылку мне также пришлось удалить) только на верхнем уровне содержит 1620 процессов.
Например, только один из процессов (из 1620 высокоуровневых) «8.1.2.5 Управление архитектурой предприятия» разбивается на огромное число более детальных бизнес-процессов.
Если идти «снизу» – как Вы предлагаете: от «самого детального» к верхнеуровневому, то можно идти «всю жизнь» даже для небольшой части процессов из «наиболее известного классификатора».
Т.е. для совсем небольшой задачи – да, можно идти снизу.
Но вот именно так: «тупо сесть рядом с сотрудником и смотреть, что же он делает, зачем, как ходят те или иные бумажки» — это только для совсем микроскопической задачи (небольшого процесса) или с огромным штатом BPM-работников, «тупо сидящих рядом».
Вообще, в ОДНОМ кросс-функциональном процессе задействовано (по определению) много сотрудников и несколько участвующих подразделений.
К тому же: при описании детальных процессов — досконально формализуется документооборот, что на верхнем уровне совсем не нужно.
Сразу признаюсь, что я ни разу не пытался разобраться в бизнес-процессах и ни разу не строил-не классифицировал; статьи, подобные Вашей, я читаю на хабре потому, что давно задолбался бесхозяйственностью и неразберихой, которая творится вокруг, и надеюсь увидеть объяснение «для самых маленьких» и понять, что вообще за нафиг вокруг творится, например, почему, когда в фирме кончаются деньги, обычно не происходит попыток оптимизировать процессы, уволить сотрудников-«дежурных по курилке», разобраться, почему при таких закупочных ценах на комплектуху и закупщика третья машина за два года…
Насколько я понимаю назначение анализа бизнес-процессов, его назначение:
— убедиться, что работа не дублируется
— убедиться, что место работы и место принятия решения единственные (т.е. заявка и решение не курсируют по всему зданию, и чтобы купить стул вахтеру не нужна подпись гендира), и одинаковые задачи решаются одинаковым способом
— убедиться, что за контроль и исполнение отвечают разные люди, не связанные друг с другом
— убедиться, что за каждое движение и актив хоть кто-то отвечает, чтобы при успехе самый наглый не говорил «Я!», а при провале — «Они!»
— обеспечить полную загрузку персонала, лишних сократить или отправить расширять бутылочное горлышко
— разобраться, какие процессы создают ценность, а какие ни денег не приносят, ни другим отделам не помогают, а «так исторически повелось»; лишнее сократить
— разобраться, какие процессы (например, часть информационных) можно переложить на автоматические системы
Начальство обычно имеет в голове картинку «как надо» или верит в магию рядовых исполнителей и низовых руководителей; отчеты при движении вверх всегда теряют деталировку и приукрашиваются. Другой вопрос, заплатят ли они аналитику, если он покажет «как есть», а особенно «как надо».
Про программу и автоматическое формирование процессов мне слышать немного странно: в программировании стараются управлять сложностью и бороться с текущими абстракциями, для чего придумали кучу приёмов, в том числе неизменяемые состояния, паттерны, KISS, SOLID. Наверняка в 90х сходные задачи анализа бизнес-процессов решались вручную и иногда даже успешно (по факту внедрения), а потом началось размножение сущностей без очевидной нужды. Мне в такие моменты вспоминается стандарт USB: большой, но в нем есть части, про которые можно сказать «это не про меня, это не читаю», а остальные понятны. Вот есть у Вас полторы тыщи процессов верхнего уровня, сколько из них максимум встречаются в одной фирме? Сколько из них конфликтуют, т.е. не должны быть в одной фирме? Какая часть из них дублирует друг друга? Ну и, наконец, кто-то может удержать в голове полной дерево сверху вниз хотя бы для половины из них?
Насколько я понимаю назначение анализа бизнес-процессов, его назначение:
— убедиться, что работа не дублируется
— убедиться, что место работы и место принятия решения единственные (т.е. заявка и решение не курсируют по всему зданию, и чтобы купить стул вахтеру не нужна подпись гендира), и одинаковые задачи решаются одинаковым способом
— убедиться, что за контроль и исполнение отвечают разные люди, не связанные друг с другом
— убедиться, что за каждое движение и актив хоть кто-то отвечает, чтобы при успехе самый наглый не говорил «Я!», а при провале — «Они!»
— обеспечить полную загрузку персонала, лишних сократить или отправить расширять бутылочное горлышко
— разобраться, какие процессы создают ценность, а какие ни денег не приносят, ни другим отделам не помогают, а «так исторически повелось»; лишнее сократить
— разобраться, какие процессы (например, часть информационных) можно переложить на автоматические системы
Начальство обычно имеет в голове картинку «как надо» или верит в магию рядовых исполнителей и низовых руководителей; отчеты при движении вверх всегда теряют деталировку и приукрашиваются. Другой вопрос, заплатят ли они аналитику, если он покажет «как есть», а особенно «как надо».
Про программу и автоматическое формирование процессов мне слышать немного странно: в программировании стараются управлять сложностью и бороться с текущими абстракциями, для чего придумали кучу приёмов, в том числе неизменяемые состояния, паттерны, KISS, SOLID. Наверняка в 90х сходные задачи анализа бизнес-процессов решались вручную и иногда даже успешно (по факту внедрения), а потом началось размножение сущностей без очевидной нужды. Мне в такие моменты вспоминается стандарт USB: большой, но в нем есть части, про которые можно сказать «это не про меня, это не читаю», а остальные понятны. Вот есть у Вас полторы тыщи процессов верхнего уровня, сколько из них максимум встречаются в одной фирме? Сколько из них конфликтуют, т.е. не должны быть в одной фирме? Какая часть из них дублирует друг друга? Ну и, наконец, кто-то может удержать в голове полной дерево сверху вниз хотя бы для половины из них?
Насколько я понимаю назначение анализа бизнес-процессов, его назначение:
В целом верно. Но несколько шире.
Начальство обычно имеет в голове картинку «как надо» … Другой вопрос, заплатят ли они аналитику, если он покажет «как есть», а особенно «как надо».
Да, часто руководство пытается удержать «весь BPM» только в своей голове. Причем в путанном варианте (каша из): «to be», «as is» и «as really is» (как на самом деле, не путать с «as is»). См. заставку к habrahabr.ru/post/305720
или верит в магию рядовых исполнителей и низовых руководителей; отчеты при движении вверх всегда теряют деталировку и приукрашиваются.
Да, " теряют и приукрашиваются ". Если говорить про идеологию «процессного офиса», то она имеет много общего с проектным офисом: в обоих случаях наибольшая ценность от них в том, что они дают НЕЗАВИСИМОЕ суждение и сопровождают проекты \ процессы вне функциональной иерархии подчиненности. Когда один из них подчинен не напрямую Директору — часто все идет «наперекос», т.к. теряется «самое главное» их свойство \ преимущество.
Про программу и автоматическое формирование процессов
Выше была выдержка из описания FoxManager.
вспоминается стандарт USB
речь про наследника com-порта? Не понял аналогию.
Вот есть у Вас полторы тыщи процессов верхнего уровня, сколько из них максимум встречаются в одной фирме?
В большинстве случаев эти процессы есть у всех. Только многие их не замечают или не хотят замечать. Например, «архитектура предприятия» — должна быть у любого предприятия, но мало кого ее наличие волнует.
Возможно, наиболее близкая к айтишникам будет аналогия с ИТСМом: если посмотреть на указанные, например, в книжке ИТИЛ процессы, то если подумать: все они, так или иначе, присутствуют даже в небольшой компании. Другое дело, что почти все они «крутятся» в головах исполнителей и не формализованы в документах компании.
Большие компании иногда «замечают крупняк» и его документируют \ регламентируют (лидер: «управление инцидентами»).
Но это не означает, что других процессов, указанных в ИТИЛ — в компании нет, они есть, только «еще не заслужили внимания» или «их еще не разглядели».
Например, там где есть даже небольшая автоматизация — в каталог процессов компании (в раздел ИТ) можно смело включать набор процессов из ИТИЛ.
Неважно, что все они могут быть сосредоточены всего в двух сотрудниках: «ИТ-директор компании» и «системный администратор».
ИТИЛ — это детализация концепций (подходов) BPM \ CBOK в части ИТ (управление процессами ИТ), впрочем как и PMBOK — в части проектной деятельности (там тоже речь о процессах).
Спасибо, я что-то понял, а про что-то понял, что не понимаю. Можете чуть подробнее сказать:
1. Есть какие-то процессы, которые есть в любой организации по умолчанию, но не всегда четко определены. Как Вы снимаете допрос по ним: сначала описываете процесс, а потом спрашиваете, как оно реализовано, или используете duck type — задаёте вопросы по частям, однозначно относящимся к процессу, а потом пытаетесь создать единую картинку для процесса целиком?
2. Вопрос в вакууме: до какого разумного момента можно игнорировать процесс, не расписывая его? Сколько человек должно быть задействовано в процессе, чтобы задуматься — а не расписать ли.
В каждом топике про BPM есть комментарий с обвинением в алхимии, это часто правда — его пока прибыльнее преподавать или внедрять в чужих фирмах, чем закладывать в план развития своей фирмы, не будучи специализированным бизнес-аналитиком. Я хочу разобраться как (и стоит ли?) внедрять BPM самостоятельно.
1. Есть какие-то процессы, которые есть в любой организации по умолчанию, но не всегда четко определены. Как Вы снимаете допрос по ним: сначала описываете процесс, а потом спрашиваете, как оно реализовано, или используете duck type — задаёте вопросы по частям, однозначно относящимся к процессу, а потом пытаетесь создать единую картинку для процесса целиком?
2. Вопрос в вакууме: до какого разумного момента можно игнорировать процесс, не расписывая его? Сколько человек должно быть задействовано в процессе, чтобы задуматься — а не расписать ли.
Да, " теряют и приукрашиваются ". Если говорить про идеологию «процессного офиса», то она имеет много общего с проектным офисом: в обоих случаях наибольшая ценность от них в том, что они дают НЕЗАВИСИМОЕ суждение и сопровождают проекты \ процессы вне функциональной иерархии подчиненностиВот этот момент я не понял. Можете сказать, где посмотреть определения «проектный офис» и «процессный офис»?
речь про наследника com-порта? Не понял аналогию.Ага. Аналогия в том, что классов в спецификации много, но их описания вынесены в отдельные разделы, содержащие только специфичные вещи.
В каждом топике про BPM есть комментарий с обвинением в алхимии, это часто правда — его пока прибыльнее преподавать или внедрять в чужих фирмах, чем закладывать в план развития своей фирмы, не будучи специализированным бизнес-аналитиком. Я хочу разобраться как (и стоит ли?) внедрять BPM самостоятельно.
Спасибо, я что-то понял, а про что-то понял, что не понимаю.
А я даже этого и не понял…
Я конечно готов поделиться своими взглядами на мир бизнес-процессов, но «войну и мир» по бизнес-процессам в одном комментарии от меня не ждите.
Как Вы снимаете допрос по ним
Разные подходы, причем многие, которые работают по описанию детальных процессов, не работают при описании высокоуровневых. Про высокоуровневые – будет в следующих частях (уже вижу, что не в одной).
до какого разумного момента можно игнорировать процесс,
предела нет. Картинка здесь:
Большие обсуждения здесь:
и здесь.
где посмотреть определения «проектный офис» и «процессный офис»?
гугл (для начала).
внедрять BPM самостоятельно.
Какой BPM внедрять — то? Все понимают под этим термином – разное (см. цикл «мухи и котлеты»).
В этом во многом и есть «феномен BPM», = все «за», но что же это такое?
Я конечно готов поделиться своими взглядами на мир бизнес-процессов, но «войну и мир» по бизнес-процессам в одном комментарии от меня не ждите.И не надеялся, хотел ссылок — и получил их, спасибо.
Разные подходы, причем многие, которые работают по описанию детальных процессов, не работают при описании высокоуровневыхМногие сложные для непосвященного вещи часто объясняются как «рисуем сову». Всё звучит очень по-умному и на первый взгляд понятно, но как доходит до применения, начинаются сложности. Собственно, поэтому я и задаю откровенно тупые вопросы, если уж нельзя посмотреть на работу из-за плеча.
Вы пишете: «Спустя год, Федеральная служба государственной статистики (Росстат) обязала всех поголовно юридических лиц представлять реестр бизнес-процессов компании и задействованных в них ее структурных подразделений.»
Буду благодарен за ссылку на документ, в котором отражены обязанности. Сайт Росстата да и Google обязательств не находят.
Буду благодарен за ссылку на документ, в котором отражены обязанности. Сайт Росстата да и Google обязательств не находят.
3. Теперь можно пояснить, как понимается концептуальное проектирование СОУ. Основная идея концептуального проектирования СОУ заключается в том, что проектируемые СОУ понимаются как человеко-машинные воплощения определённых теоретико-системных схем.
Теорий и тогда и сейчас — много, но нужны простые практические методики и с примерами. Методику инвентаризации высокоуровневых процессов на основе любой теории — подскажете?
Вот и я про тоже.
Экскурс в прошлое, мы обсуждали здесь:
Научная организация труда (НОТ) … и т.п.
31.05.2016 at 00:18 Bipiem says:
Хорошие и правильные вопросы Вы задаете. На некоторые из них я пытался ответить в предыдущих статьях и обсуждениях к ним.
Но если применительно к этой статье, т.е. сфокусироваться на первоочередной — простейшей практической задаче BPM: просто \ тупо посчитать все высокоуровневые (хотя бы) процессы компании, то выясняется, что уже ЭТО огромная проблема. Почему?
Как можно решать сложные задачи, не определив базовые понятия, подходы, составить «таблицу умножения» по BPM. Многие конечно скажут, что есть методология АРИС и т.п., есть CBOK и т.п., но это скорее пособия по алхимии, чем научные подходы.
«опыт внедрения» и «эффективного применения технологии BPM» — много «такого добра», но не подтвержденного. В массе случаев, это просто пиар.
Я уверен, что в современном BPM «львиная доля» — не как что-то оптимизировать, а как заработать на оптимизации: точнее алхимии, выдаваемой за оптимизацию.
Но если применительно к этой статье, т.е. сфокусироваться на первоочередной — простейшей практической задаче BPM: просто \ тупо посчитать все высокоуровневые (хотя бы) процессы компании, то выясняется, что уже ЭТО огромная проблема. Почему?
Как можно решать сложные задачи, не определив базовые понятия, подходы, составить «таблицу умножения» по BPM. Многие конечно скажут, что есть методология АРИС и т.п., есть CBOK и т.п., но это скорее пособия по алхимии, чем научные подходы.
«опыт внедрения» и «эффективного применения технологии BPM» — много «такого добра», но не подтвержденного. В массе случаев, это просто пиар.
Я уверен, что в современном BPM «львиная доля» — не как что-то оптимизировать, а как заработать на оптимизации: точнее алхимии, выдаваемой за оптимизацию.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Считаем бизнес-процессы. Введение