Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 15
Спасибо, за сборник цЫтат и аббревиатур. Больше нечего сказать.
На здоровье.
Надеюсь, что у всех проминусовавших хватило сил прочитать статью целиком. И хотя бы немного подумать.
Надеюсь, что у всех проминусовавших хватило сил прочитать статью целиком. И хотя бы немного подумать.
Знаете, я вот минусануть не могу, но честно говоря — плюсовать тут тоже не за что. Понятно что вы старались, но скажем прямо — читать сложно, и понять, что вы хотели донести, еще сложнее.
Ну так, просто для примера: совершенно не ясно осталось, куда вы собрались выкинуть (отделить) IT составляющую, с всеми ее BPMN, SOA и пр.? Сами по себе большинство перечисленных аббревиатур, методик и пр. гроша ломаного не стоят. Я совершенно не хочу сказать, что без BPMN никуда, наоборот — у подобных нотаций есть масса врожденных недостатков, от которых практически невозможно полностью избавиться.
Никуда без приложений — поэтому в идеале методика должна давать на выходе приложение. Никуда не уйти и без существующих приложений — поэтому нужно интегрироваться с уже написанным их зоопарком. Это реальная рутина, которая вполне способна погубить любой проект.
Ну так, просто для примера: совершенно не ясно осталось, куда вы собрались выкинуть (отделить) IT составляющую, с всеми ее BPMN, SOA и пр.? Сами по себе большинство перечисленных аббревиатур, методик и пр. гроша ломаного не стоят. Я совершенно не хочу сказать, что без BPMN никуда, наоборот — у подобных нотаций есть масса врожденных недостатков, от которых практически невозможно полностью избавиться.
Никуда без приложений — поэтому в идеале методика должна давать на выходе приложение. Никуда не уйти и без существующих приложений — поэтому нужно интегрироваться с уже написанным их зоопарком. Это реальная рутина, которая вполне способна погубить любой проект.
понять, что вы хотели донести, еще сложнее.
Картинки понятны?
куда вы собрались выкинуть (отделить) IT составляющую, с всеми ее BPMN, SOA и пр.?
ИТ- в отдельный слой. Везде присутствует декомпозиция и абстрагирование одного слоя от другого, например, в том же стеке сетевых протоколов: прикладной, (другие), сетевой, канальный, физический. Вы строите IP-маршрутизацию на сетевом не зная, какой у вас канальный и прикладной.
В принципе, точно также вы проектируете процессный уровень, без углубления в специфику ИТ (канальный) и бизнес-модель (прикладной). У каждого уровня свои задачи, свои принципы. Конечно они связаны, но проектируются независимо.
Может вообще не будет ИТ, а все процессы ручные. Или 50 на 50: бывает основной вариант — доставка информации по е-почте, а резервный — конверт в зубы и на трамвай.
Вопрос что первично: «процессы или ИТ» – философский, как и «бытие или сознание», «курица или яйцо» и т.п. Однако, в современном мире пока первично ИТ, но лишь благодаря причинам, указанным в обоих статьях.
Никуда без приложений — поэтому в идеале методика должна давать на выходе приложение.
Посмотрите п. 2.5 Пример проекта BPM aka BPA
Подобные проекты часто вообще не подразумевают автоматизацию, а лишь желание разобраться, что уже «на-автоматизировано». Более подробно на этом остановлюсь в третьей главе.
Подскажите бестолковому, почему некоторые комментарии требуют премодерацию, а другие нет? Как убрать премодерацию?
Картинки понятны?
куда вы собрались выкинуть (отделить) IT составляющую, с всеми ее BPMN, SOA и пр.?
ИТ- в отдельный слой. Везде присутствует декомпозиция и абстрагирование одного слоя от другого, например, в том же стеке сетевых протоколов: прикладной, (другие), сетевой, канальный, физический. Вы строите IP-маршрутизацию на сетевом не зная, какой у вас канальный и прикладной.
В принципе, точно также вы проектируете процессный уровень, без углубления в специфику ИТ (канальный) и бизнес-модель (прикладной). У каждого уровня свои задачи, свои принципы. Конечно они связаны, но проектируются независимо.
Может вообще не будет ИТ, а все процессы ручные. Или 50 на 50: бывает основной вариант — доставка информации по е-почте, а резервный — конверт в зубы и на трамвай.
Вопрос что первично: «процессы или ИТ» – философский, как и «бытие или сознание», «курица или яйцо» и т.п. Однако, в современном мире пока первично ИТ, но лишь благодаря причинам, указанным в обоих статьях.
Никуда без приложений — поэтому в идеале методика должна давать на выходе приложение.
Посмотрите п. 2.5 Пример проекта BPM aka BPA
Подобные проекты часто вообще не подразумевают автоматизацию, а лишь желание разобраться, что уже «на-автоматизировано». Более подробно на этом остановлюсь в третьей главе.
Подскажите бестолковому, почему некоторые комментарии требуют премодерацию, а другие нет? Как убрать премодерацию?
Премодерация — это для лентяев типа меня, которым комментировать хочется, а статьи писать лениво или некогда.
>>куда вы собрались выкинуть (отделить) IT составляющую, с всеми ее BPMN, SOA и пр.?
>ИТ- в отдельный слой. Везде присутствует декомпозиция и абстрагирование одного слоя от другого,
Ну так ктож против декомпозиции? Вопрос только в одном — чтобы декомпозировать, особенно IT от остального, нужно формализовать на каком-то языке интерфейсы между уровнями. Мой опыт мне говорит, что скажем BPMN для этого годится плохо, и свои цели, как их декларируют, не достигает по ряду причин. Так что ждем на этот вопрос ответа дальше.
>>куда вы собрались выкинуть (отделить) IT составляющую, с всеми ее BPMN, SOA и пр.?
>ИТ- в отдельный слой. Везде присутствует декомпозиция и абстрагирование одного слоя от другого,
Ну так ктож против декомпозиции? Вопрос только в одном — чтобы декомпозировать, особенно IT от остального, нужно формализовать на каком-то языке интерфейсы между уровнями. Мой опыт мне говорит, что скажем BPMN для этого годится плохо, и свои цели, как их декларируют, не достигает по ряду причин. Так что ждем на этот вопрос ответа дальше.
Спасибо за такой объём материала и свежий взгляд.
Я сам пришёл к схожим выводам, будучи изначально обычным разработчиком, побыв недолго менеджером продукта и представляя сейчас объединение веток управления ИТ-подразделением и менеджмента качества в компании.
И мне крайне близок подход PTSM. Но до появления этой статьи я начал задумываться — может быть что то не так и я не прав/нет опыта или понимания: весь мир говорит об ITIL/Lean/BPM/ISO 9000/ТОС и т.п., но никто не объединяет эти подходы и не пытается выстроить общую разумную модель. Но теперь я спокоен и полностью удовлетворён — я двигаюсь в правильном направлении и мои выводы, в целом, верны.
По сути статьи, могу добавить, что при использовании описанного подхода в достаточно крупной компании имеет смысл в найме специального человека, который будет понимать и бизнес на уровне стратегии, и бизнес на уровне операционном и ИТ на уровне всех процессов ITIL и саму суть работы компании. Это должен быть грамотный CIO/CQO или иной CxO, который сможет организовать координацию всех участников и продвигать на всех уровнях компании разумные методы и политики.
Проблема только в том, что таких специалистов, на мой взгляд, слишком мало и ещё меньше компаний, готовых подобный подход внедрять
Я сам пришёл к схожим выводам, будучи изначально обычным разработчиком, побыв недолго менеджером продукта и представляя сейчас объединение веток управления ИТ-подразделением и менеджмента качества в компании.
И мне крайне близок подход PTSM. Но до появления этой статьи я начал задумываться — может быть что то не так и я не прав/нет опыта или понимания: весь мир говорит об ITIL/Lean/BPM/ISO 9000/ТОС и т.п., но никто не объединяет эти подходы и не пытается выстроить общую разумную модель. Но теперь я спокоен и полностью удовлетворён — я двигаюсь в правильном направлении и мои выводы, в целом, верны.
По сути статьи, могу добавить, что при использовании описанного подхода в достаточно крупной компании имеет смысл в найме специального человека, который будет понимать и бизнес на уровне стратегии, и бизнес на уровне операционном и ИТ на уровне всех процессов ITIL и саму суть работы компании. Это должен быть грамотный CIO/CQO или иной CxO, который сможет организовать координацию всех участников и продвигать на всех уровнях компании разумные методы и политики.
Проблема только в том, что таких специалистов, на мой взгляд, слишком мало и ещё меньше компаний, готовых подобный подход внедрять
весь мир говорит об ITIL/Lean/BPM/ISO 9000/ТОС
не так давно весь мир считал, что земля плоская.
смысл в найме специального человека ...
Я иного мнения. Должна быть наука (дисциплина process tech), которая показала бы, что земля круглая и затмения естественные (подходы к формализации и организации трудовой деятельности), а практическая методичка позволила бы обычному студенту стать таким «специальным человеком». Пока нет ни того ни другого, а в почете жрецы и алхимики.
Со временем букварь «Архитектура предприятия» или азбуку «процессо-ведение» будут изучать в школе. Только они будут очень далеки от сегодняшнего «привычного» понимания EA и BPM.
не так давно весь мир считал, что земля плоская.
смысл в найме специального человека ...
Я иного мнения. Должна быть наука (дисциплина process tech), которая показала бы, что земля круглая и затмения естественные (подходы к формализации и организации трудовой деятельности), а практическая методичка позволила бы обычному студенту стать таким «специальным человеком». Пока нет ни того ни другого, а в почете жрецы и алхимики.
Со временем букварь «Архитектура предприятия» или азбуку «процессо-ведение» будут изучать в школе. Только они будут очень далеки от сегодняшнего «привычного» понимания EA и BPM.
Это был бы идеальный мир…
Я работаю в группе компаний, в которой частью компании является управление качеством и бизнес-технологи.
Как ни странно, в ВУЗах учат и таких, но они не имеют никакого реального опыта и, как следствие, на самом нижнем уровне они прекрасно работают, но как только в их зоне ответственности появляются процессы уровня предприятия и конвертации стратегических целей в конкретные задачи или сквозные процессы из цепочки создания ценностей, знания перестают играть большую роль, а включается уже опыт.
Я поясню, почему считаю необходимым специального человека:
1. Как бы то ни было — бизнес-технологи и ИТ редко добавляют стоимость к продукции компании — они являются ресурсом для участников производства и, как следствие, для многих руководителей из основной цепочки — вся эта деятельность вторична.
2. Основные задачи специалистов и руководителей, создающих продукцию и приносящие прибыль компании — это делать продукцию и приносить прибыль, а не организовывать процессы вне своей сферы деятельности
3. Технолог всегда снаружи всей иерархии и он может видеть процессы со стороны. Особенно сквозные процессы, охватывающие несолько подразделений и часто он единственный, кроме нескольких топ-менеджеров имеет представление о проблемах, связанных именно с коммуникацией между подразделениями
Исходя из списка выше — я для себя сделал вывод — специальный человек не просто может «драйвить» проблемы — он обязан это делать как бы ни сопротивлялись руководители.
По факту — специальный человек намного лучше понимает баланс между административными задачами и основной деятельностью компании
Я работаю в группе компаний, в которой частью компании является управление качеством и бизнес-технологи.
Как ни странно, в ВУЗах учат и таких, но они не имеют никакого реального опыта и, как следствие, на самом нижнем уровне они прекрасно работают, но как только в их зоне ответственности появляются процессы уровня предприятия и конвертации стратегических целей в конкретные задачи или сквозные процессы из цепочки создания ценностей, знания перестают играть большую роль, а включается уже опыт.
Я поясню, почему считаю необходимым специального человека:
1. Как бы то ни было — бизнес-технологи и ИТ редко добавляют стоимость к продукции компании — они являются ресурсом для участников производства и, как следствие, для многих руководителей из основной цепочки — вся эта деятельность вторична.
2. Основные задачи специалистов и руководителей, создающих продукцию и приносящие прибыль компании — это делать продукцию и приносить прибыль, а не организовывать процессы вне своей сферы деятельности
3. Технолог всегда снаружи всей иерархии и он может видеть процессы со стороны. Особенно сквозные процессы, охватывающие несолько подразделений и часто он единственный, кроме нескольких топ-менеджеров имеет представление о проблемах, связанных именно с коммуникацией между подразделениями
Исходя из списка выше — я для себя сделал вывод — специальный человек не просто может «драйвить» проблемы — он обязан это делать как бы ни сопротивлялись руководители.
По факту — специальный человек намного лучше понимает баланс между административными задачами и основной деятельностью компании
Статья хорошая, очень подробный разбор рынка.
Конкретно бизнес-процесс — логистическое view. Пример: покупаем карандаши. Куда отправить заявку, кто ее получит и когда, куда он побежит у кого он купит. Бизнес-процесс? Бизнес-процесс. Лучше чтобы их кто-то инженерил.
Enterprise level — это стратегия (что мы сделали, делаем и куда вообще хотим идти своей долбаной компанией) + структура предприятия.
Business Process Level — уже понятно. Логистические схемы. Что и как покупаем, продаем, сбываем производим. Все цепочки.
Infrastructure Level — маппинг людей, должностей и отделов на бизнес-процессы.
IT Infrastructure Level — информационные системы нужно выделять в отдельное view.
Financial Level — надо добавить. «токовая» модель, куда втекают денежки, куда вытекают. Чтобы мы знали что мы неубыточны своей компанией.
Так, судя по вашему анализу, видно что это все в ужасном состоянии от одной терминологии можно шею свернуть. Так этому учить совершенно нельзя. Напрудили прудов.
Конкретно бизнес-процесс — логистическое view. Пример: покупаем карандаши. Куда отправить заявку, кто ее получит и когда, куда он побежит у кого он купит. Бизнес-процесс? Бизнес-процесс. Лучше чтобы их кто-то инженерил.
Enterprise level — это стратегия (что мы сделали, делаем и куда вообще хотим идти своей долбаной компанией) + структура предприятия.
Business Process Level — уже понятно. Логистические схемы. Что и как покупаем, продаем, сбываем производим. Все цепочки.
Infrastructure Level — маппинг людей, должностей и отделов на бизнес-процессы.
IT Infrastructure Level — информационные системы нужно выделять в отдельное view.
Financial Level — надо добавить. «токовая» модель, куда втекают денежки, куда вытекают. Чтобы мы знали что мы неубыточны своей компанией.
Так, судя по вашему анализу, видно что это все в ужасном состоянии от одной терминологии можно шею свернуть. Так этому учить совершенно нельзя. Напрудили прудов.
Спасибо за оценку.
Разговоры о сложном нужно начинать с простых примеров. Какая сложная функция не была бы, но подстановка в нее простых значений должна давать результат и по ним можно понять ее поведение.
Поэтому я прошу приводить простые и конкретные примеры при описании «сложных и профессиональных подходов к BPM и EA».
Например, есть коммерческий детский садик «Бизнес-ясли» с незатейливой орг-структурой:…
Но меня отсылают на авторские тренинги.
Разговоры о сложном нужно начинать с простых примеров. Какая сложная функция не была бы, но подстановка в нее простых значений должна давать результат и по ним можно понять ее поведение.
Поэтому я прошу приводить простые и конкретные примеры при описании «сложных и профессиональных подходов к BPM и EA».
Например, есть коммерческий детский садик «Бизнес-ясли» с незатейливой орг-структурой:…
Но меня отсылают на авторские тренинги.
Сила мысли впечатляет. В уме у тебя конечно кавардак. Если дальше будешь мыслить с такой же силой, то через 2-4 года в этой области ума наступит порядок.
Да, процессы и бизнес-процессы это весело :) Маркетинг такой маркетинг. Ну любой более менее знающий спец по процессам в курсе этого. А другим это не особо интересно. Остается узкий слой на грани которых это может впечатлить.
Далее, ты говоришь что шаг один, шаг два это процесс. Это не так. Это также и процедура. А в чем отличие процесса от процедуры?
Разница лишь в том что результат процесса — продукт. А результат процедуры — все что угодно.
Далее ты говоришь что есть продуктовые процессы. Беда в том что других нет. В бизнесе все процессы продуктовые. Абсолютно. Если нет продукта, значит это не процесс. Так написано в ИСО 9000. Ну и я с этим согласен.
Ты говоришь продукт или услуга. Это тоже самое что сказать «собака или пудель». Нарушение логики видишь? Услуга это продукт. Не может быть союза «или» между ними.
Ну я плюсанул чисто за силу мысли. Ценность материала очень низкая. Ты показал кашу в своей голове. Ну как бы она у нас у всех там есть. Надо брать что то узкое. Пользы будет больше.
Но тк я когда то такую же фигню писал, то понимаю. Я 10 лет потратил на изучение этого бреда. Теперь жалею. Пошел в бизнес и все стало сильно проще. Слой неадекватности стачивается в голове на много быстрее. Потому если хочешь еще больше усилить мысль, забей на это все и иди в бизнес. Делай качественные продукты нужные рынку. И ты поймешь что такое процессы.
Да, процессы и бизнес-процессы это весело :) Маркетинг такой маркетинг. Ну любой более менее знающий спец по процессам в курсе этого. А другим это не особо интересно. Остается узкий слой на грани которых это может впечатлить.
Далее, ты говоришь что шаг один, шаг два это процесс. Это не так. Это также и процедура. А в чем отличие процесса от процедуры?
Разница лишь в том что результат процесса — продукт. А результат процедуры — все что угодно.
Далее ты говоришь что есть продуктовые процессы. Беда в том что других нет. В бизнесе все процессы продуктовые. Абсолютно. Если нет продукта, значит это не процесс. Так написано в ИСО 9000. Ну и я с этим согласен.
Ты говоришь продукт или услуга. Это тоже самое что сказать «собака или пудель». Нарушение логики видишь? Услуга это продукт. Не может быть союза «или» между ними.
Ну я плюсанул чисто за силу мысли. Ценность материала очень низкая. Ты показал кашу в своей голове. Ну как бы она у нас у всех там есть. Надо брать что то узкое. Пользы будет больше.
Но тк я когда то такую же фигню писал, то понимаю. Я 10 лет потратил на изучение этого бреда. Теперь жалею. Пошел в бизнес и все стало сильно проще. Слой неадекватности стачивается в голове на много быстрее. Потому если хочешь еще больше усилить мысль, забей на это все и иди в бизнес. Делай качественные продукты нужные рынку. И ты поймешь что такое процессы.
Странно все это. В том числе:
А результат процедуры — все что угодно.
«все что угодно» — значит и продукт тоже?
Услуга это продукт.Не может быть союза «или» между ними.
Почему-то интернет пестрит: «Каталог продуктов и услуг», «Каталог товаров и услуг»?
Люди не понимают, что пишут?
За оценку «Силы мысли» — отдельное спасибо. Сам порой удивляюсь, как они все в моей черепушке умещаются и не давят.
А результат процедуры — все что угодно.
«все что угодно» — значит и продукт тоже?
Услуга это продукт.Не может быть союза «или» между ними.
Почему-то интернет пестрит: «Каталог продуктов и услуг», «Каталог товаров и услуг»?
Люди не понимают, что пишут?
За оценку «Силы мысли» — отдельное спасибо. Сам порой удивляюсь, как они все в моей черепушке умещаются и не давят.
Да, в результате процедуры в том числе может получиться продукт. Ровно тот же что и в процессе. Но состав описанных шагов в процессе и в процедуре будет отличаться. Это не простая мысль. Надо потратить не один год на описание процессов чтобы понять что такое процедура и где она нужна. В статье про 7П я приводил примеры http://systemo.biz/7p-idealnaya-biznes-model-organizatsii/
>> Почему-то интернет пестрит: «Каталог продуктов и услуг», «Каталог товаров и услуг»?
>> Люди не понимают, что пишут?
Ты думаешь что все написанное в Интернете это истина? Или удивляет то что кто то в Интернете не прав? Товары и услуги, также как и товары или услуги — это верная формулировка. В ней нет противоречий. Проблема там где люди начинают противопоставлять услуги и продукты. Хотя услуга это лишь разновидность продукта, ровно такая же как и товар. Это показатель булькающего холодца в головах людей. Если ты этого еще не понял, то скоро поймешь. 99% людей не понимают значение 80% слов которые они употребляют. Они путаюст свои домыслы и шаблоны с реальностью. Не способны отличить картину мира от реального мира. 99% людей уверены что живут в реальном мире и живут так как будто что то знают.
>> Почему-то интернет пестрит: «Каталог продуктов и услуг», «Каталог товаров и услуг»?
>> Люди не понимают, что пишут?
Ты думаешь что все написанное в Интернете это истина? Или удивляет то что кто то в Интернете не прав? Товары и услуги, также как и товары или услуги — это верная формулировка. В ней нет противоречий. Проблема там где люди начинают противопоставлять услуги и продукты. Хотя услуга это лишь разновидность продукта, ровно такая же как и товар. Это показатель булькающего холодца в головах людей. Если ты этого еще не понял, то скоро поймешь. 99% людей не понимают значение 80% слов которые они употребляют. Они путаюст свои домыслы и шаблоны с реальностью. Не способны отличить картину мира от реального мира. 99% людей уверены что живут в реальном мире и живут так как будто что то знают.
Спасибо, впервые нашёл статью, на столько полно отражающую мои сомнения в современном классическом ИТ-консалтинге и бизнес-аналитике в частности.
Выделю своими словами особо понравившиеся тезисы (из обоих глав), они на мой взгляд относятся не только к BPM:
Это далеко не полный список аргументов в статье, написанной пусть и не достаточно складно/гладко, но ёмко и как говорят «в правду – матку». При этом нет цели огульно подвергнуть методологию сомнению, есть даже реальные предложения её упорядочить, правда со справедливой оговоркой, что как только она станет понятной, потеряет свою солидность и как следствие стоимость.
Вообще, выражаю респект храбрости автора. Надеюсь Вы представляете на что замахнулись. Я не про индустрию, ей совершенно не грозят никакие сомнения. Гиганты этой индустрии подкрепили голуютеометодологию реальным софтом, местами так удачно, что уже не разберёшь где курица, а где яйцо. Я про хлеб и опору тех серьезных парней, посвятивших этому жизнь и карьеру, ставших признанными гуру, сертифицированных вышеупомянутыми гигантами, всегда дорогих и востребованных на HR рынке в ИТ сфере. Думаю они будут очень недовольны таким подходом к святому.
Выделю своими словами особо понравившиеся тезисы (из обоих глав), они на мой взгляд относятся не только к BPM:
- Монетизация теологии (не всякая религия добилась такого коммерческого успеха)
- Сапожники без сапог (обещая измерить все и вся, ИТ-шники не способны дать поддающуюся реальному подсчету единицу измерения собственных услуг)
- Чем непонятнее тем дороже, (за новыми аббревиатурами скоро не то что Wiki, алфавит не будет успевать)
- Нам что кухня, что космос, BPM рулит («грамотному» консультанту не важна отрасль/специфика, процесс он и в Африке процесс)
- Умный консультант отвечает за описание/моделирование/автоматизацию контроля процесса, но ни в коем случае за его результат
Это далеко не полный список аргументов в статье, написанной пусть и не достаточно складно/гладко, но ёмко и как говорят «в правду – матку». При этом нет цели огульно подвергнуть методологию сомнению, есть даже реальные предложения её упорядочить, правда со справедливой оговоркой, что как только она станет понятной, потеряет свою солидность и как следствие стоимость.
Вообще, выражаю респект храбрости автора. Надеюсь Вы представляете на что замахнулись. Я не про индустрию, ей совершенно не грозят никакие сомнения. Гиганты этой индустрии подкрепили голую
впервые нашёл статью, на столько полно отражающую …
Хочется верить, что «из искры возгорится пламя».
Я про хлеб и опору тех серьезных парней, посвятивших этому жизнь и карьеру,
Из моих диалогов с пользователями Хабра:
< … на мой взгляд, часть алхимиков осознаёт, что они выглядят алхимиками — тот же …
<< Они почти все это понимают. Только, к сожалению, они нам не помогут.
У нас это «на общественных началах», а для них это «хлеб насущный».
Но хочется верить, что будут исключения.
Думаю они будут очень недовольны
Посмотрите профильные группы на Facebook
Обсуждение статьи на других ресурсах:
bpmsoft.org
club.cnews.ru
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Бизнес-процессы: Как все запущено и запутано. Глава Вторая «Мухи и котлета»