Source: http://www.itblogs.ru/blogs/borkus/archive/2007/10/05/_170430043A0443043F04300439044204350441044C04_-_3B0435043A043004400441044204320430043C043804_-_2D002D00_-_3F043E043A043004_-_3D043504_-_3F043E04370434043D043E042100_.aspx
Выборы выборами, а идеи по новым мерам «регулирования» не иссякают. Как сообщает «Коммерсант» в Думе рассматривается закон о создании еще семи новых ЕГАИС. Затронет это фармрынок, рынок аудивидеопродукции, автомобильных запчастей и пр. Так как внесен он лидерами главной партии, то сомнений с том, что он будет принят нет. Собственно, опыт ЕГАИС всем известен -- ясно, что с поставками и в других отраслях начнутся сбои.
Так что пора запасаться лекарствами и зачастями. :))
Подробности – в источнике
http://www.kommersant.ru/doc.aspx?DocsID=811624
Published 5 октября 2007 г. 13:47 by Vlad Borkus Edit
Filed under: Законы
Tolik said:О! Отличный пример для дискуссии про формализацию бизнес-процессов. Вот введут они эту хрень - ИТ-процессов добавится изрядно. И меняться они будут часто. И оптимальным уровнем документирования (пока не утрясется) будет именно "документирование" на уровне программного кода.
Потом, когда утрясется - может быть и формально опишем.
Кстати - он же пример об It does matter - вот в такие моменты ВНУТРЕННИЕ ИТ-ресурсы создают конкурентные преимущества. И я повеселюсь глядя на компании, где "процессы отстроены", "централизованы", "внедрены лучшие бизнес-практики" и т.д. и т.п. ...
октября 5, 2007 14:50
Vlad Borkus said:
>Отличный пример для дискуссии про формализацию бизнес-процессов.
Толя, я толкьо на часть твоего комментрария среагирую, если не возражаешь. В продолжение обсуждения, начатого elsewhere...
В предлагаемой тобой модели код надо интенсивно комментировать -- тогда можно жить и с ним. Но ты же знаешь программистов, над ними только ослабь контроль. А в итоге автор кода не может понять, что код делает уже через полгода....
Есть еще такая вещь: описание процесса в системе BPM -- это та же программа, просто имещая дело с примитивами другого рода, более близкими бизнесу. Да и сам язык программирования в BPM визуальный, что тоже снижает барьеры.
А оборотная сторона BPM -- этот язык заведомо упрощен, потому треюуются готовые блоки для сборки процесса. Посему он имеет ограничения по использованию, но все рано -- полезен же.
октября 5, 2007 16:31
nvoynov said:
да ЕГАИС у вас там отжигает
to Tolik
копеечку про дискуссию о процессах ... В общем "серебрянных пуль то нету и в ближайшее время не предвидится" (вольный перевод Брукса). И тем не менее на проблемы нужно смотреть с разных сторон так лучше получается общий результат. Т.е. процессы не панацея, но где-то могут помочь, тем более не отстроенные раз и навсегда, а гибкие и легко модифицируемые.
И на затравку как человеку, который когда-то программировал, и знает принципы вынесения изменений ... представить систему конструктор из собственно бедненькой ИС - только БД, BRMS - бизнес правила в другой системе общие на компанию, BPMS - бизнес-процессы - тоже из ИС выделены ... красивая картинка вырисовывается, не так?
октября 5, 2007 17:50
Tolik said:
Ага, картинка (теоретически) красивая, на практике - нету таких систем, а ежели её кто и сделает - будут дикие тормоза от неэффективной реализации, недостаток нужных кирпичиков и дико неудобная среда программирования с крайне узкими "под обычного пользователями" функциями
Не проще ли - библиотека классов с бизнес-логикой - и сборка из них приложения в любой IDE, которая годами вылизана под удобное программирование, иметт отладчик и т.д. и т.п.
октября 6, 2007 10:32
nvoynov said:
> to Vlad
> BPM визуальный и заведомо упрощенный
Мне кажется, что немного искажен смыл. Поэтому добавлю еще 5 копеек.
BPMN - графическая нотация моделирования - "визуальный язык" наверное не слишком корректный термин, т.к. просто не язык. BPEL - как раз язык исполнения процессов, хотя его и визуализируют, но все же он не визуальный.
Попробую еще раз грубо очертить основные моменты. Примитивы BPMN - это как раз бизнес-примитивы. "Получить заявку", "Обработать заявку", "Заказать товар", "Доставить товар клиенту". BPMN сам имеет три типа диаграмм, по мере усложнения взаимодействия, от абстрактной модели процесса, через модель процесса с точки зрения одного участника взаимодействующего с другими участниками посредством сообщений, и до полного описания всех процессов взаимодействия внутри каждого из участников. (похоже покрывает два уровня описания вариантов использования по Алистеру Коберну - уровня облака и уровня моря)
Примитивы BPEL - это тоже скорее бинес-примитивы, но уже более низкого порядка, наверное немного ниже третьего уровня BPMN, более близкие к примитивам выражаемым привычными программными средствами и оформленные в виде сервисов. Но средства взаимодействия посредством сообщений уже обретают программные очертания. Т.к. это уже сервисы, WSDL.
Т.е. BPEL это уже вполне осознанный процесс с точки зрения разработчиков, потому что он организовывает сервисные операции (программный код) "формирует заказы", "отсылает уведомление контролирующему лицу", "требовать подтверждения заказа от руководителя".
Красота всего этого хозяйства, что это "относительно просто моделируется" и затем относительно просто развертывается. При этом "довольно просто" модифицируется. Ну и то что процессы выделены из системы, и их не нужно реализовывать в системе - т.е. экономия на трудно-впихуемых и затем трудно-реализуемых вещей.
> to Tolik
> компании, где "процессы отстроены", "централизованы", "внедрены лучшие
> бизнес-практики" и т.д. и т.п. ..
И это наверное не организация бизнеса - это относительно дешевое воплощение организации процессов бизнеса в ИТ инфраструктуре предприятия. Где "отстроенный" процес можно быстро перестроить, рецентрализовать и выкинуть устаревшие, но когда-то "лучшие бизнес-практики".
октября 6, 2007 10:58
nvoynov said:
> картинка (теоретически) красивая, на практике - нету таких систем
> будут дикие тормоза от неэффективной реализации, недостаток ..
Тут тоже интересно, по идее "неэффективная реализация" можно отнести к взаимодействию систем. Сами же системы должны быть эффективными, по крайней мере разработчики наверное стремяться.
> нужные кирпичики
> Не проще ли - библиотека классов с бизнес-логикой ...
Нужные кирпичики я думаю стандартизируются, как это было с процессами.
Смысл тот же самый, но такая библиотека тоже скорее миф, т.к. никто ее до сих пор не сделал. Делают по прежнему системы, в которых почти все можно создать, из того что туда "понапихано" и вот как раз разнообразие этих вариантов реализации, мне кажется хуже чем стандартная система
октября 6, 2007 11:52
Выборы выборами, а идеи по новым мерам «регулирования» не иссякают. Как сообщает «Коммерсант» в Думе рассматривается закон о создании еще семи новых ЕГАИС. Затронет это фармрынок, рынок аудивидеопродукции, автомобильных запчастей и пр. Так как внесен он лидерами главной партии, то сомнений с том, что он будет принят нет. Собственно, опыт ЕГАИС всем известен -- ясно, что с поставками и в других отраслях начнутся сбои.
Так что пора запасаться лекарствами и зачастями. :))
Подробности – в источнике
http://www.kommersant.ru/doc.aspx?DocsID=811624
Published 5 октября 2007 г. 13:47 by Vlad Borkus Edit
Filed under: Законы
Comments
Tolik said:О! Отличный пример для дискуссии про формализацию бизнес-процессов. Вот введут они эту хрень - ИТ-процессов добавится изрядно. И меняться они будут часто. И оптимальным уровнем документирования (пока не утрясется) будет именно "документирование" на уровне программного кода.
Потом, когда утрясется - может быть и формально опишем.
Кстати - он же пример об It does matter - вот в такие моменты ВНУТРЕННИЕ ИТ-ресурсы создают конкурентные преимущества. И я повеселюсь глядя на компании, где "процессы отстроены", "централизованы", "внедрены лучшие бизнес-практики" и т.д. и т.п. ...
октября 5, 2007 14:50
Vlad Borkus said:
>Отличный пример для дискуссии про формализацию бизнес-процессов.
Толя, я толкьо на часть твоего комментрария среагирую, если не возражаешь. В продолжение обсуждения, начатого elsewhere...
В предлагаемой тобой модели код надо интенсивно комментировать -- тогда можно жить и с ним. Но ты же знаешь программистов, над ними только ослабь контроль. А в итоге автор кода не может понять, что код делает уже через полгода....
Есть еще такая вещь: описание процесса в системе BPM -- это та же программа, просто имещая дело с примитивами другого рода, более близкими бизнесу. Да и сам язык программирования в BPM визуальный, что тоже снижает барьеры.
А оборотная сторона BPM -- этот язык заведомо упрощен, потому треюуются готовые блоки для сборки процесса. Посему он имеет ограничения по использованию, но все рано -- полезен же.
октября 5, 2007 16:31
nvoynov said:
да ЕГАИС у вас там отжигает
to Tolik
копеечку про дискуссию о процессах ... В общем "серебрянных пуль то нету и в ближайшее время не предвидится" (вольный перевод Брукса). И тем не менее на проблемы нужно смотреть с разных сторон так лучше получается общий результат. Т.е. процессы не панацея, но где-то могут помочь, тем более не отстроенные раз и навсегда, а гибкие и легко модифицируемые.
И на затравку как человеку, который когда-то программировал, и знает принципы вынесения изменений ... представить систему конструктор из собственно бедненькой ИС - только БД, BRMS - бизнес правила в другой системе общие на компанию, BPMS - бизнес-процессы - тоже из ИС выделены ... красивая картинка вырисовывается, не так?
октября 5, 2007 17:50
Tolik said:
Ага, картинка (теоретически) красивая, на практике - нету таких систем, а ежели её кто и сделает - будут дикие тормоза от неэффективной реализации, недостаток нужных кирпичиков и дико неудобная среда программирования с крайне узкими "под обычного пользователями" функциями
Не проще ли - библиотека классов с бизнес-логикой - и сборка из них приложения в любой IDE, которая годами вылизана под удобное программирование, иметт отладчик и т.д. и т.п.
октября 6, 2007 10:32
nvoynov said:
> to Vlad
> BPM визуальный и заведомо упрощенный
Мне кажется, что немного искажен смыл. Поэтому добавлю еще 5 копеек.
BPMN - графическая нотация моделирования - "визуальный язык" наверное не слишком корректный термин, т.к. просто не язык. BPEL - как раз язык исполнения процессов, хотя его и визуализируют, но все же он не визуальный.
Попробую еще раз грубо очертить основные моменты. Примитивы BPMN - это как раз бизнес-примитивы. "Получить заявку", "Обработать заявку", "Заказать товар", "Доставить товар клиенту". BPMN сам имеет три типа диаграмм, по мере усложнения взаимодействия, от абстрактной модели процесса, через модель процесса с точки зрения одного участника взаимодействующего с другими участниками посредством сообщений, и до полного описания всех процессов взаимодействия внутри каждого из участников. (похоже покрывает два уровня описания вариантов использования по Алистеру Коберну - уровня облака и уровня моря)
Примитивы BPEL - это тоже скорее бинес-примитивы, но уже более низкого порядка, наверное немного ниже третьего уровня BPMN, более близкие к примитивам выражаемым привычными программными средствами и оформленные в виде сервисов. Но средства взаимодействия посредством сообщений уже обретают программные очертания. Т.к. это уже сервисы, WSDL.
Т.е. BPEL это уже вполне осознанный процесс с точки зрения разработчиков, потому что он организовывает сервисные операции (программный код) "формирует заказы", "отсылает уведомление контролирующему лицу", "требовать подтверждения заказа от руководителя".
Красота всего этого хозяйства, что это "относительно просто моделируется" и затем относительно просто развертывается. При этом "довольно просто" модифицируется. Ну и то что процессы выделены из системы, и их не нужно реализовывать в системе - т.е. экономия на трудно-впихуемых и затем трудно-реализуемых вещей.
> to Tolik
> компании, где "процессы отстроены", "централизованы", "внедрены лучшие
> бизнес-практики" и т.д. и т.п. ..
И это наверное не организация бизнеса - это относительно дешевое воплощение организации процессов бизнеса в ИТ инфраструктуре предприятия. Где "отстроенный" процес можно быстро перестроить, рецентрализовать и выкинуть устаревшие, но когда-то "лучшие бизнес-практики".
октября 6, 2007 10:58
nvoynov said:
> картинка (теоретически) красивая, на практике - нету таких систем
> будут дикие тормоза от неэффективной реализации, недостаток ..
Тут тоже интересно, по идее "неэффективная реализация" можно отнести к взаимодействию систем. Сами же системы должны быть эффективными, по крайней мере разработчики наверное стремяться.
> нужные кирпичики
> Не проще ли - библиотека классов с бизнес-логикой ...
Нужные кирпичики я думаю стандартизируются, как это было с процессами.
Смысл тот же самый, но такая библиотека тоже скорее миф, т.к. никто ее до сих пор не сделал. Делают по прежнему системы, в которых почти все можно создать, из того что туда "понапихано" и вот как раз разнообразие этих вариантов реализации, мне кажется хуже чем стандартная система
октября 6, 2007 11:52
Комментариев нет:
Отправить комментарий