Страница 1 из 4 1234 ПоследняяПоследняя
Показано с 1 по 30 из 120
  1. #1
    Член сообщества
    Регистрация
    15.12.2005
    Сообщений
    73

    По умолчанию Этапы автоматизации процессов

    Есть некий текст. Можно ли его как-то обсудить.


    Этапы автоматизации процессов




    Регламенты и процессы - вот в чем вопрос. Как сделать так, чтобы процессы и регламенты отражали друг друга.
    Первый этап.

    Существует или разрабатывается нормативный документ, например, Регламент.
    В соответствии с Регламентом организуется процесс в натуре, автоматизация процесса может быть как полная, так и частичная.
    Прямая связь между нормативным документом и процессом в натуре отсутствует.
    http://www.ecm-journal.ru/blog/image...eefb4a4d7c.png
    Второй этап.

    Существует или разрабатывается нормативный документ.
    Разрабатывается нормативная модель, т.е. реализуется формализованный нормативный документ средствами моделирования .
    На основе нормативной модели разрабатывается процесс в натуре.
    Прямые связи между нормативным документом, нормативной моделью и процессом в натуре отсутствует.
    Третий этап.

    Существует или разрабатывается нормативный документ.
    Разрабатывается нормативная модель.
    На основе нормативной модели разрабатывается исполнительная модель и реализуется процесс в натуре.
    Прямые связи между нормативным документом, нормативной моделью и исполнительной моделью отсутствуют. Зато есть связь между исполнительной моделью и процессом в натуре, но только в смысле регулирования – запустить остановить предписанное действие, выбрать действие из существующей альтернативы.
    Связь по управлению структурой отсутствует (внесение изменений в структуру).
    Проблемы метода.

    Проблемы нисходящего и восходящего изменения нормативного документа. Проблемы возникают при изменении нормативного документа по приведению в соответствие нормативной модели, исполнительной модели и процесса в натуре. Аналогичные проблемы возникают при изменении процесса в натуре и приведение в соответствие вышестоящих элементов.
    http://www.ecm-journal.ru/blog/image...2da08c5e98.png
    Необходимость преобразования (четвертый этап)

    Из последней схемы видно, что две модели – это много проблем по внесению изменений, а в постоянно меняющемся мире постоянное перепроектирование моделей – нонсенс. Кроме этого происходит раделение труда: как надо делать определяет тот, кто никогда этого не делал (проектировщик моделей), а тот, который все делает становится тупым приложением к компьютеру, если он проявит инициативу, тут же будет наказан за непослушание.
    Лицо, заинтересованное в результатах работы, растворилось.
    Ну, и что делать?

    Нужно упразднить обе модели и сделать полную модель деятельности. Полнота модели определяется на стороне процесса в натуре.
    Нужен нормативный документ, однозначно интерпретируемый в полную модель. А полная модель, однозначно интерпретируемая в процесс в натуре. Обратное восхождение от процесса к документу, аналогично, должно быть однозначным. Иными словами, пропадает разница между нормативным документом и моделью, это всего лишь разные формы представления одного и того же. В полной модели (нормативном документе) должно быть, по крайней мере два уровня представления (управления): управление структурами и регулирование процессами.

  2. #2
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    -- Этапы автоматизации процессов
    А при чем здесь "автоматизация"? У вас же все про регламентацию процессов?

    -- На основе нормативной модели разрабатывается процесс в натуре.
    Я конечно сильно извиняюсь, но это ведь чушь собачья ... ой, то есть немного странно выглядит.
    Кому нужен абстрактный процесс, полученный неизвестно как из головы неизвестно кого и не связанный с реальной деятельностью?

    дальше даже обсуждать неохота.

  3. #3
    Член сообщества
    Регистрация
    15.12.2005
    Сообщений
    73

    По умолчанию Александру Болдину

    Спасибо за ответ
    --На основе нормативной модели разрабатывается процесс в натуре
    Я тоже дико извиняюсь, но такова технология, например, связанная с госуслугами.
    Имеется нормативный документ, который утверждает регламент услуги. Как создавался этот регламент, в предложенном для обсуждения тексте не рассматривается, главное, что регламент уже есть. Примеры регламентов можно глянуть на gosuslugi.ru.
    Текст содержит попытку представить развитие регламентации и возможности автоматизации регламентов.
    На первом этапе автоматизация отсутствует. Регламент представляет собой текстовый документ содержащий набор правил. Исполнитель регламента действует на свой страх и риск, в соответствии с собственным пониманием регламента.

  4. #4
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Если мы говорим о госрегламентах - тут ситуация действительно иная. Модельные процессы существуют чаще всего где-нибудь в другой стране и перекочевывают к нам вместе путешествующими в заграницах чиновниками. Аки вирусы.
    Вот и получаются регламенты где при встрече посетителя чиновник кланяется и говорит "Конитиваа" потом предлагает заполнить анкету справа-налево и сверху-вниз, а провожет вас словами "Мерси бьен, Оревуар".

    Я-то подумал, что вы про бизнес-процессы, а тема с теми регламентами она как бы и вообще не тема.

  5. #5
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    Question Можно уточнить?

    Цитата Сообщение от algol
    Есть некий текст. Можно ли его как-то обсудить.
    Этапы автоматизации процессов
    К каким процессам относится данный текст?
    Процессы бывают очень разные.
    1. Например так называемые "Исполняемые процессы" (из которых состоит документооборот, бухучет, финпланирование и т.д.). В них нормативная модель, очень часто жестко закреплена (законодательно или программно) и, практически, не меняется. По таким процессам настраивают информационные системы. Исполнительная модель совпадает с Нормативной.
    2. "Процессы управления" - содержат "нелинейный элемент" в виде человека, который, очень часто, может волюнтаристским образом менять и тасовать "Технологические процессы" в том порядке, который позволит получить оптимальный, с его точки зрения, результат.
    То есть: Создавать множество Нормативных моделей для "Процесса управления" - гиблое дело.
    3. Остаются "Технологические процессы" - где вариабельность имеет место, но не слишком велика, чтобы ее нельзя было учесть при проектировании. К ним относятся процессы предоставления госуслуг, хотя часто и эти процессы закреплены законодательным образом. Например, процессы получения льгот и субсидий, - пока гражданин не соберет нужное количество справок и подтверждающих документов, даже в Единое окно соваться бесполезно, а после Единого окна проходит жестко закрепленная процедура проверки документов и вынесения решения. Sic!
    То есть, прошу определить область применимости и ограничения для предложенной Вами модели.
    С уважением Виталий.
    P.S. Мне приходилось встречать регламенты предоставления госуслуг, где половину текста занимало описание требований к месту предоставления госуслуги (количество стульев в коридоре, количество столов и кубометров воздуха на человека, температура, влажность и и т.д.)

  6. #6
    Член сообщества
    Регистрация
    15.12.2005
    Сообщений
    73

    По умолчанию

    Виталий, мне трудно так сразу выполнить классификацию по предложенной шкале.
    Попробую дать пояснения.
    Область применения [FONT='Verdana','sans-serif']модели – деятельность, связанная с оказанием государственных услуг.[/FONT]
    [FONT='Verdana','sans-serif']1.Притом, что на каждую услугу разрабатывается некий комплект нормативных документов, в них, как правило, определены ключевые моменты. Поэтому жесткими их назвать нельзя. [/FONT]
    2.В большинстве случаев участвует «нелинейный элемент», который принимает решения в индивидуальном порядке.
    3. Это именно государственные услуги.
    Требования к количеству стульев, входов-выходов, огнетушителей, туалетов и т.д. - это обычные требования к присутственным местам, которые определены СНиПами и другими документами, и имеют отношение к помещениям независимо от владельца.
    Электронизация государства, общества и госуслуг поднимает проблему скорости реакции системы автоматизации на изменения, как нормативных условий (документов, условно изменения сверху), так и условий деятельности, связанной с госуслугами снизу (требования потребителя, исполнителя услуги, внедрение новой технологии и т.п.).
    Современные автоматизированные регламенты (регламенты, реализованные в автоматизированных системах), как мы видим, на схеме 3, имеют разрыв с нормативной моделью и с нормативным документом.
    Интенсивность нормотворчества в области госуслуг возросла на порядки, потребности к изменениям снизу, соответственно частота и количество переделок автоматизированных регламентов, имеют тенденцию к существенному росту.
    Возникла явная потребность в разработке модели (в том числе регламента предоставления госуслуг) которая обеспечивала бы возможность автоматизированного нормотворчества и автоматического формирования исполнительной модели, с одной стороны и возможность внесения изменений в исполнительную модель снизу с отражением этих изменений в нормотворчество. И все это в режиме реального времени.
    Хотелось бы обсудить возможности реализации подобной системы.

  7. #7
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    Цитата Сообщение от algol
    Виталий, мне трудно так сразу выполнить классификацию по предложенной шкале.
    Попробую дать пояснения.
    Область применения [FONT='Verdana','sans-serif']модели – деятельность, связанная с оказанием государственных услуг.[/font]
    [FONT='Verdana','sans-serif']1.Притом, что на каждую услугу разрабатывается некий комплект нормативных документов, в них, как правило, определены ключевые моменты. Поэтому жесткими их назвать нельзя. [/font]
    2.В большинстве случаев участвует «нелинейный элемент», который принимает решения в индивидуальном порядке.
    В большинстве своем госуслуги регламентированы в подзаконных актах. Наличие "индивидуального порядка" предоставления госуслуг существенно повышает их коррупционную емкость.
    Требования к количеству стульев, входов-выходов, огнетушителей, туалетов и т.д. - это обычные требования к присутственным местам, которые определены СНиПами и другими документами, и имеют отношение к помещениям независимо от владельца.

    Ну это был экзотический пример, с которым мне пришлось столкнуться 3 года назад, при автоматизации предоставления госуслуг, поэтому я привел его в постскриптуме.
    Электронизация государства, общества и госуслуг поднимает проблему скорости реакции системы автоматизации на изменения, как нормативных условий (документов, условно изменения сверху), так и условий деятельности, связанной с госуслугами снизу (требования потребителя, исполнителя услуги, внедрение новой технологии и т.п.).

    С этим сложнее, поскольку изменение законов и подзаконных актов требует изменения алгоритмов автоматизации предоставления госуслуг. Как правило, автоматизация предоставления госуслуг решается с помощью ПО документооборота, то есть требуется изменение алгоритмов и условий маршрутизации документов, справок, запросов. Такая необходимость возникает обычно "сверху", необходимость "снизу" - практически не встречал, - не любят чиновники проявлять инициативу.
    Современные автоматизированные регламенты (регламенты, реализованные в автоматизированных системах), как мы видим, на схеме 3, имеют разрыв с нормативной моделью и с нормативным документом.

    Схему 3 привели Вы, а мне разрыв модели и норматива, говорит только о безграмотной реализации норматива. Есть ряд программных продуктов, которые, не имея полного функционала документооборота, вынуждают внедренцев подстраивать потребности жизни, под возможности продукта. Это и вызывает разрыв.
    Интенсивность нормотворчества в области госуслуг возросла на порядки, потребности к изменениям снизу, соответственно частота и количество переделок автоматизированных регламентов, имеют тенденцию к существенному росту.
    Возникла явная потребность в разработке модели (в том числе регламента предоставления госуслуг) которая обеспечивала бы возможность автоматизированного нормотворчества и автоматического формирования исполнительной модели, с одной стороны и возможность внесения изменений в исполнительную модель снизу с отражением этих изменений в нормотворчество. И все это в режиме реального времени.
    Хотелось бы обсудить возможности реализации подобной системы.
    А в чем проблема с реализацией такой системы? Просто нужно выбирать системы документооборота с достаточным функционалом, а не самые дешевые.
    С уважением Виталий.

  8. #8

    По умолчанию

    Ужас какой, блог не о чем.... , да и ответы тоже

    мужики будьте проще, посещаемость Вашего форума сильно уменьшилась , в основном из за неумения экспертов форума давать простые ответы на поставленные вопросы. Виталий Геннадиевич, Вам не обязательно показывать что Вы умный, все это и так знают что Вы пишите книги...

  9. #9

    По умолчанию

    неумения экспертов форума давать простые ответы на поставленные вопросы
    Рита, попробуйте дать простой ответ, на заданный выше вопрос. Я по наивности увидел знакомую фразу "автоматизация процессов", открыл тему, прочитал вопрос, ужаснулся, закрыл тему

    Человек задал вопрос
    Как сделать так, чтобы процессы и регламенты отражали друг друга.
    и сам тут же расписал все этапы и дал ответ
    Нужно упразднить обе модели и сделать полную модель деятельности.
    Получается, это даже не вопрос был, а просто мысли вслух... Нужен ли здесь какой-то ответ вообще?

    Рита, Вы ещё не читали про метод определения оптимального числа грузчиков с помощью характеристической функции вероятностного распределения, путем обратного преобразования Фурье. Там очень интересно про полиномы, абстракции...
    Последний раз редактировалось Петров Дмитрий; 29.08.2010 в 20:21.

  10. #10

    По умолчанию

    О Дмитрий, привет, когда риск менеджмент закончите, обещали в июне а уже август заканчивается?

  11. #11

    По умолчанию

    О Дмитрий, привет, когда риск менеджмент закончите, обещали в июне а уже август заканчивается?
    Следите за форумом разработчиков, там будут выкладываться бета-версии, на СФИНе, я зарёкся обсуждать подобные вещи, сочтут за рекламу...

  12. #12
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию Прелестно да?

    Цитата Сообщение от algol
    Возникла явная потребность в разработке модели (в том числе регламента предоставления госуслуг) которая обеспечивала бы возможность автоматизированного нормотворчества и автоматического формирования исполнительной модели, с одной стороны и возможность внесения изменений в исполнительную модель снизу с отражением этих изменений в нормотворчество. И все это в режиме реального времени.
    Хотелось бы обсудить возможности реализации подобной системы.
    К сожалению, идея автоматизированной разработки/корректировки регламентов не оправдала себя. "К сожалению" - потому что я сам в это верил в оптимистическом 2000 году, когда казалось что все дело в технических возможностях компьютеров и правильно разработанном софте. Однако, столкновение с реальностью разрушает и не такие красивые идеи.
    И что характерно, наблюдается эффект инерции: с одной стороны разработчики регламентов напрочь отказались от идеи авторегламентации, с другой стороны разработчики программ по моделированию бизнес-процессов продолжают пиарить и развивать эту никому не нужную функциональность. Смешно не правда ли?

    Да и сама ситуация с моделированием бизнес-процессов сегодня - это просто театр абсурда. Надежды на какой-то единый стандарт давно в прошлом, модельеры и те кто работает в процессах живут в непересекающихся пространствах, софта для имитационного моделирования б/п нет, софта для увязывания б/п, показателей, оргструктуры нет ... При этом компании зачем-то покупают за бешенные деньги некие кособокие программные конструкции ... чтобы потом разочароваться, выбросить их и купить другую такую же ерунду.

    При этом в параллельном мире САПР происходит настоящая революция - там разработчики почему-то делают не то что интересно им, а то что нужно пользователям. Удивительно, не правда ли?

  13. #13
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    Цитата Сообщение от Рита Конго
    Ужас какой, блог не о чем.... , да и ответы тоже
    мужики будьте проще, посещаемость Вашего форума сильно уменьшилась , в основном из за неумения экспертов форума давать простые ответы на поставленные вопросы. Виталий Геннадиевич, Вам не обязательно показывать что Вы умный, все это и так знают что Вы пишите книги...
    Ну, Рита!
    1. Писать книги и быть умным, - это далеко не одно и то же.
    2. Прежде чем ответить человеку в такой тональности, я перечитал все 40 постов от algol и ответил в его ключе. Если Вы возражаете против нашего с ним разговора, мы с ним можем уйти в "личку" или на mail. Форум опустеет еще больше, останется только "политбюро на кухне", где решают вселенские проблемы "нового мира" или "расчет точки бифуркации грузчиков путем преобразования поллитры в ряд Фурье".
    3. У сложной проблемы не бывает простого ответа, каков вопрос, таков и ответ.
    С уважением Виталий.

  14. #14
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Согласен со всем кроме п. 3. - тут не совсем:
    У сложных проблем почти всегда простые решения. Однако ответ на вопрос по сложной проблеме чрезвычайно труден - как так передать решение заказчику чтобы не услышать в ответ:" Да я и без тебя знал, что решение с грузчиками это бригадный подряд - ты мне ряды Фурье давай, или системы дифуравнений 54-го порядка, чтобы это обосновать начальству".

    PS. Кстати, именно поэтому ученичество у даосов длится долго и не сопровождается обучением в европейском смысле - пока человек сам не поймет смысл коэна о хлопке одной ладонью, бесполезно идти дальше.

    PPS. Кстати, если так работать с заказчиком - т.е. не навязывать ему авторитетное книжно-гуристическое мнение, а совместно с его менеджерами решать проблемы фирмы ... трудно заработать на консалтинге адекватные деньги. Поэтому я и не работаю в консалтинге :-Р

  15. #15
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    Цитата Сообщение от Александр Болдин
    Согласен со всем кроме п. 3. - тут не совсем:
    У сложных проблем почти всегда простые решения. Однако ответ на вопрос по сложной проблеме чрезвычайно труден - как так передать решение заказчику чтобы не услышать в ответ:" Да я и без тебя знал, что решение с грузчиками это бригадный подряд - ты мне ряды Фурье давай, или системы дифуравнений 54-го порядка, чтобы это обосновать начальству"....
    Если "сложная проблема" имеет "простое решение", в чем ее сложность?
    Любая сложная проблема, вызывается целым рядом причин, а не одной. Рассмотреть эти причины, выстроить их по приоритетам, возможностям устранения, рискам и т.д. - уже это сложно.
    Простой ответ в сложном случае: "Да здесь всю систему менять надо!" - меня (и заказчика), как правило, не устраивает.
    С уважением Виталий.

  16. #16

    По умолчанию

    Писать книги и быть умным, - это далеко не одно и то же.
    НЕ кокетничайте , Вы умный :-)

  17. #17
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    Цитата Сообщение от Рита Конго
    НЕ кокетничайте , Вы умный :-)
    Спасибо за комплимент, но вот книги сейчас писать не получается, - не хватает времени.
    Лучше скажите мне: "Можно, я останусь на форуме?"
    С уважением Виталий.

  18. #18
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от eliferov
    Если "сложная проблема" имеет "простое решение", в чем ее сложность?
    В менеджменте, в отличие от других областей знания, сложность проблемы в 90% случаев происходит от нежелания видеть решение. Оставшиеся 10% это влияние непредсказуемых факторов типа изменений законодательства, колебаний конъюнктуры и т.п.
    Соответственно, в 90% случаев процесс решения проблемы = процессу доказательства клиенту "правильности" заранее известного решения. Если есть время, можно исподволь подвести клиента к осознанию сопровождая процесс магическими пассами и чтением мантр про Фурье-преобразование. Если времени нет, приходится поступать жестко: "Послушайте, господин Гунявый, но ведь все пацаны так делают - век воли не видать". Или что то же самое: "Оптимизация бизнес процессов направлена на сохранение позитивных стереотипов, выработанных сотрудниками в процессе работы, а также привносит лучшие практики работы компаний вашей отрасли" :-Р
    Цитата Сообщение от eliferov
    Любая сложная проблема, вызывается целым рядом причин, а не одной. Рассмотреть эти причины, выстроить их по приоритетам, возможностям устранения, рискам и т.д. - уже это сложно.
    Простой ответ в сложном случае: "Да здесь всю систему менять надо!" - меня (и заказчика), как правило, не устраивает.
    Простой ответ простому ответу рознь. Если бухгалтерия заказчика не знает базовых правил бухучета, то ее надо менять. Целиком. Начиная с главного бухгалтера. Несмотря на то, что это - супруга брата генерального. Простое решение? А вы пробовали уволить супругу брата генерального? То-то.

    Закапывание в сложность чаще всего попытка убежать, спрятаться от простого решения (помните плакат про страусов и бетонный пол?) :-Р

    Если собственник в противовес "наглому ГД" натолкал ему в топы телеуправляемых надсмотрщиков без согласования с которыми шагу нельзя ступить, можно ли требовать от такой фирмы эффективности? Смеетесь, да?
    Простое решение это чаще всего выбор между 2-мя вариантами. В описанном случае: (1) или собственник отходит от дел доверяя ГД и контролируя его по годовым финпоказателям (2) или сам собственник становится к штурвалу и берет на себя всю (ВСЮ!) полноту ответственности.

    PS. Весело: в момент отправки в форум этого поста решилась одна из сложных проблем, которую полгода пытались пробить и так и эдак. Но потом все таки продавили, используя метод Гудериана - создание численного преимущества на узком участке фронта.
    Последний раз редактировалось А.Б.; 30.08.2010 в 16:53.

  19. #19

    По умолчанию

    К сожалению, идея автоматизированной разработки/корректировки регламентов не оправдала себя. "К сожалению" - потому что я сам в это верил в оптимистическом 2000 году, когда казалось что все дело в технических возможностях компьютеров и правильно разработанном софте. Однако, столкновение с реальностью разрушает и не такие красивые идеи.
    По роду своей деятельности просто не могу не поинтересоваться А что конкретно не устраивает в современных системах для бизнес-моделирования? Что можно сделать вручную такого, чего нельзя получить из программы? Я не собираюсь спорить и переубеждать, просто интересно мнение человека со стороны, который уже много лет этим занимается.

    И что характерно, наблюдается эффект инерции: с одной стороны разработчики регламентов напрочь отказались от идеи авторегламентации, с другой стороны разработчики программ по моделированию бизнес-процессов продолжают пиарить и развивать эту никому не нужную функциональность. Смешно не правда ли?
    «Разработчики регламентов» - это кто? Если консультанты, то да, я согласен, в большинстве своём они не хотят применять программный продукты, потому что это для них лишняя головная боль. Большинство предпочитает пользоваться собственными шаблонами документов, разработанными ещё в дремучих 90-х, им так удобнее. И то, есть примеры консалтинговых фирм, которые всё же применяют продукты для бизнес-моделирования. Например, у Business Studio есть мощный партнёр – консалтинговая компания в Запорожье.

    При этом в параллельном мире САПР происходит настоящая революция - там разработчики почему-то делают не то что интересно им, а то что нужно пользователям. Удивительно, не правда ли?
    САПР – это те кто «автоматизация проектных работ» или те кто «SAP/R3»?

  20. #20
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    Цитата Сообщение от Александр Болдин
    ...Простой ответ простому ответу рознь. Если бухгалтерия заказчика не знает базовых правил бухучета, то ее надо менять. Целиком. Начиная с главного бухгалтера. Несмотря на то, что это - супруга брата генерального. Простое решение? А вы пробовали уволить супругу брата генерального? То-то.
    Если собственник в противовес "наглому ГД" натолкал ему в топы телеуправляемых надсмотрщиков без согласования с которыми шагу нельзя ступить, можно ли требовать от такой фирмы эффективности? Смеетесь, да?
    Простое решение это чаще всего выбор между 2-мя вариантами. В описанном случае: (1) или собственник отходит от дел доверяя ГД и контролируя его по годовым финпоказателям (2) или сам собственник становится к штурвалу и берет на себя всю (ВСЮ) полноту ответственности.
    Да проходил я на проектах все эти ситуации...
    1. В первой ситуации, - брали внятного замглавбуха, который знал и умел. А еще был случай, когда главбух возомнил себя финдиром, вот было сложно объяснять ему и гендиру, что это немножко разные области компетенции.
    2. Во второй, - объяснял "смотрящим", что они должны контролировать, по каким показателям и критериям, и где кончаются полномочия гендира. Да еще и регламентировал эти полномочия, создавая из "смотрящих" орган "а ля совет директоров".
    3. В третьей, - выстраивал для собственника такую систему отчетных показателей, отчетов и информации, чтобы он все знал и по минимуму вмешивался в оперативные и мелкие вопросы. А вот когда его старые друзья пытались бегать к собственнику "через голову гендира", клянчить и кляузничать, - бил им по рукам. Однажды даже пришлось уволить директора департамента, одного из отцов-основателей(правда он еще и подворовывал).
    Кто скажет что все эти три случая были решены "просто", - пусть первый бросит в меня камень.
    С уважением Виталий.

  21. #21
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от Петров Дмитрий
    По роду своей деятельности просто не могу не поинтересоваться. А что конкретно не устраивает в современных системах для бизнес-моделирования? Что можно сделать вручную такого, чего нельзя получить из программы? Я не собираюсь спорить и переубеждать, просто интересно мнение человека со стороны, который уже много лет этим занимается.
    Знаете чем отличается консультант от менеджера?
    Для консультанта (даже бывшего) главное - схема бизнес-процесса. Регламент он воспринимает как досадную рутину, мешающую ему насладиться рисованием ажурных конструкций из многоугольничков, элипсиков, стрелочек различных цветов и оттенков. Для менеджера главное в регламенте - последовательность действий, ресурсы и матрица ответственности. Схемы для него лишь иллюстрации к тексту. Это - тоже не совсем правильно, но не забывайте что менеджерам кроме регламенто-творчества надо еще работать. И желательно, чтобы разрботка регламентов занимала не более 10-20% их времени.

    К сведению и возможным вопросам: последний проект в Business Studio я закончил в марте этого года. Это - полная модель бизнес-процессов инжиниринговой компании (портфель проектов более 100 млрд руб) с декомпозицией до 4-5 уровня. Причем модели рисовали представители подразделений выполняющих процессы. Обучить их рисованию в IDEF0 оказалось проще, чем погрузить в специфику консультантов (это была 1 попытка проекта, закончившаяся ничем).
    Цитата Сообщение от Петров Дмитрий
    САПР – это те кто «автоматизация проектных работ» или те кто «SAP/R3»?
    Первые. Только сейчас это уже и не САПР, а проектирование промышленных объектов на основе 3D-4D моделирования.
    Пример описания одной из наиболее распространенных систем:
    AVEVA PDMS – это среда проектирования для всех проектных дисциплин c централизованным хранением данных, предназначенных для трехмерного проектирования промышленных предприятий. Система включает в себя модули для проектирования оборудования, трубопроводов, системы отопления, вентиляции и кондиционирования, структуры и кабельных лотков. Проектирование выполняется на основе каталога и спецификаций, стандартных изделий в трехмерной среде с помощью инструментов, которые обеспечивают отсутствие коллизий. Из модели можно автоматически получить полный набор чертежей, в том числе изометрические чертежи трубопроводов.

    Причем уже существует единый стандарт обмена данными между такими системами - на основе ISO 15926.

  22. #22
    Член сообщества
    Регистрация
    26.02.2008
    Сообщений
    51

    По умолчанию

    Здравствуйте, коллеги!
    Вы уж меня простите, но я примерно на таком же уровне, на котором идет данное обсуждение, могу разговаривать о футболе и рыбалке. Что-то об этом слышала, и даже пару раз держала удочку. Но все эти удочки - фигня полная, можно ловить и на палку с леской. Разводилово, в общем. Так?
    Вот примерно то же самое читаю на этой ветке.
    В данный момент лично я руковожу проектом автоматизации процессов одной крупной госструктуры. Определяющий документ - Регламент. И как-то мне он (регламент) вовсе не мешает. Нормальный рабочий документ. И еще есть Закон. Тоже весьма полезный в работе документ. Другой вопрос, что процесс, который описал по данному регламенту заказчик и процессЫ, которые получились в реальности, мягко говоря.... разные. Но они (точнее - деятельность в рамках процесса) полностью соответствуют требованиям регламента. "Вы просто не умеете их готовить" (с)
    Ах, да... кстати! Естественно - реализовано в BPM-системе! Не в доморощенной, не в приспособе а-ля BPMS. А в ПОЛНОЦЕННОЙ BPM-системе. И не за шестизначные цены, имейте в виду.
    И сорь топикстартеру - нормальный ответ на Ваш вопрос тянет на серьезный анализ, а это, увы, не в рамках форума. Пишу для того, чтобы сказать, что:а) можно; б) можно успешно; в) делают.

  23. #23
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от eliferov
    Да проходил я на проектах все эти ситуации...
    1. В первой ситуации, - брали внятного замглавбуха, который знал и умел. А еще был случай, когда главбух возомнил себя финдиром, вот было сложно объяснять ему и гендиру, что это немножко разные области компетенции.
    2. Во второй, - объяснял "смотрящим", что они должны контролировать, по каким показателям и критериям, и где кончаются полномочия гендира. Да еще и регламентировал эти полномочия, создавая из "смотрящих" орган "а ля совет директоров".
    3. В третьей, - выстраивал для собственника такую систему отчетных показателей, отчетов и информации, чтобы он все знал и по минимуму вмешивался в оперативные и мелкие вопросы. А вот когда его старые друзья пытались бегать к собственнику "через голову гендира", клянчить и кляузничать, - бил им по рукам. Однажды даже пришлось уволить директора департамента, одного из отцов-основателей(правда он еще и подворовывал).
    Кто скажет что все эти три случая были решены "просто", - пусть первый бросит в меня камень.
    Нет, камнем не стану, я лучше при встрече на тебя буду пивом покушаться.

    1. Классика жанра: "пат в 2 хода".
    а) Пытаемся уволить бестолкового главбуха.
    б) Не получилось - вводим толкового зама. Через 3-6 месяцев ищем нового толкового зама, потом еще ... и так до опупения. В конце концов тупая но понтярная главбухша подставляет контору по полной, так что даже ее связи не помогают выкрутиться. Результат - собственник попадает на весьма приличные бабки и спроваживает главбухшу куда подальше.
    Что мешало ему это сделать сразу? Наверное недостаток фосфора в еде.

    2. Аналогично (1)
    а) Пытаемся договориться с собственником об устранении Пашей Эмильевичей и разграничении ответственности между ним и ГД. При этом все, кроме собственника, понимают что их надо гнать поганой метлой. Не получается.
    б) Создаем из этих "топов", которые в жизни никем кроме секретарши не управляли, Совет Директоров (или что-то в этом роде). Далее они начинают "управлять" и "контролировать", параллельно подворовывая по-маленьку но часто (это-то умеют в совершенстве). Постепенно вокруг них растет аппарат из таких же лиц не обезображенных печатью интеллекта. Результат - провал крупных проектов, неизвестно куда испарившиеся миллионы и ... обвиненный во всем ГД, который надрывался все это время, пытаясь спасти бизнес и которому потом в лучшем случае удается уйти без потерь. Собственник с перманентно вставшими дыбом от увиденного волосами отстраняет всех и обращается в кадровое агентство, чтобы ему подыскали нового ГД.
    Что мешало ему принять простое решение (а)? Опять фосфор?

    Наконец случай 3 - более сложный (как бы):
    а) Консультант выстраивает систему отчетности для собственника и ходит вдоль нее с ружом, имея санкцию на увольнение саботажников. Радостный собственник видит своего ГД насквозь, тот просто счастлив - ничто так не способствует пищеварению как клизма каждый день. А как счастливы топ-жулики - не описать словами.
    б) Консультанту надоедает ходить с ружом (тем более, что платить ему за это прекращают) и он уходит на следующий проект. Собственник продолжает видеть радужную картину, но она незаметно начинает расходиться с действительностью. Дальше - все почти как в (1) и (2), но хуже, потому что ГД и топы могуть спеться и собственник как-то раз проснувшись может узнать, что это уже не его бизнес.

    Вот такие грустные дела.
    И как пишут в киноэпиграфах: Сюжет типа вымышлен и все совпадения с конкретными ситуациями и людьми случайны.

  24. #24
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию

    Цитата Сообщение от Александр Болдин
    Нет, камнем не стану, я лучше при встрече на тебя буду пивом покушаться.
    Ты сначала встреться со мной, тебя ж не найдешь. Да и пересекаемся мы иногда только в других городах.
    Вот такие грустные дела.
    И как пишут в киноэпиграфах: Сюжет типа вымышлен и все совпадения с конкретными ситуациями и людьми случайны.
    Грустные дела происходят у консультанта, когда он не может выбрать проект. В случае 3 а) + б) - я однажды отказался от такого проекта. Ну нельзя было из ...... сделать конфетку-собственника.
    Так что: "Консультант! Не хватай по жадности или неумению, все что попало. Проводи первичную диагностику топа, а еще лучше топа+собственника, и будет тебе счастье."
    С уважением Виталий.

  25. #25

    По умолчанию

    Для консультанта (даже бывшего) главное - схема бизнес-процесса. Регламент он воспринимает как досадную рутину, мешающую ему насладиться рисованием ажурных конструкций из многоугольничков, элипсиков, стрелочек различных цветов и оттенков. Для менеджера главное в регламенте - последовательность действий, ресурсы и матрица ответственности. Схемы для него лишь иллюстрации к тексту.
    Но ведь в теории именно программный продукт должен решить эту проблему, т.е., построив графически сам процесс, заполнив пару карточек, регламент формируется программой автоматически, а также всякие там ДИ, положения и т.д.. Что же идёт не так?

    К сведению и возможным вопросам: последний проект в Business Studio я закончил в марте этого года. Это - полная модель бизнес-процессов инжиниринговой компании (портфель проектов более 100 млрд руб) с декомпозицией до 4-5 уровня. Причем модели рисовали представители подразделений выполняющих процессы. Обучить их рисованию в IDEF0 оказалось проще, чем погрузить в специфику консультантов (это была 1 попытка проекта, закончившаяся ничем).
    Не хочу показаться занудой, но всё же интересно, какова основная причина, по которой Вы считаете проект неудавшимся? И какую роль в этом сыграл сам программный продукт?

    реализовано в BPM-системе!
    Так поделитесь опытом! Что это за система? Какие задачи с помощью неё решили?
    Не в приспособе а-ля BPMS. А в ПОЛНОЦЕННОЙ BPM-системе.
    Так это ж одно и то же BPMS = BPM-система.

  26. #26
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от Петров Дмитрий
    Но ведь в теории именно программный продукт должен решить эту проблему, т.е., построив графически сам процесс, заполнив пару карточек, регламент формируется программой автоматически, а также всякие там ДИ, положения и т.д.. Что же идёт не так?
    1. Не знаю, не знаю - у нас например все идет как надо :-)
    2. Если вы не понимаете, почему текст главнее картинки - могу только рекомендовать поработать несколько лет операционным менеджером в реальном бизнесе. Так чтобы на вас висела ответственность за выполнение регламентов подчиненными.
    На словах этот опыт пытаться передать бесполезно.
    Цитата Сообщение от Петров Дмитрий
    Не хочу показаться занудой, но всё же интересно, какова основная причина, по которой Вы считаете проект неудавшимся? И какую роль в этом сыграл сам программный продукт?
    Почему вы решили, что проект не удался? Он вполне так себе удачен - другое дело, что не все инициаторы с этим согласны, но на всех ведь не угодишь?
    Тут есть пара нюансов (для тех кто понимает):
    1. Проекты моделирования бизнес-процессов крупных компаний никогда не заканчиваются. Они затухают.
    2. Мнения заинтересованных лиц по поводу результатов проекта никогда не совпадают.
    3. На самом деле, главными результатами проекта являются:
    - Создание базы для регламентации, т.е.: понимания руководителями и сотрудниками что же они все таки делают, накопление и структурирование информационных материалов, пакет согласованных схем процессов.
    - Формирование группы людей которые могут на основе имеющейся информации разработать и согласовать регламенты, и обеспечить их исполнение в дальнейшем.
    Но этого вам никто не скажет...
    Цитата Сообщение от Петров Дмитрий
    Так это ж одно и то же BPMS = BPM-система.
    Возможно имелся в виду мелкий глюк с 3-мя буквами: BPM обозначает и Business Process Management и Business Performance Management. Вполне естественная ситуация для американцев - немного раздражает русских и немцев, а так ничего. Видимо главное с какими интонацией и выражением лица произносится "би пи эм эсс". :-Р

    Да кстати, BPMS под внедрение которой в России сейчас осваиваются основные бюджетные деньги называется EMC Documentum. :-Р

  27. #27
    Член сообщества
    Регистрация
    24.11.2005
    Сообщений
    3,432

    По умолчанию

    Цитата Сообщение от eliferov
    Ты сначала встреться со мной, тебя ж не найдешь. Да и пересекаемся мы иногда только в других городах.
    Ну так ведь широка страна моя родная - много в ней лесов, полей и рек.

  28. #28
    Член сообщества
    Регистрация
    15.12.2005
    Сообщений
    73

    По умолчанию Для WJ

    Описанный Вами метод автоматизации госуправления соответствует Третьему этапу в тексте, предложенном для обсуждения. А именно: "Прямые связи между нормативным документом, нормативной моделью и исполнительной моделью отсутствуют. Зато есть связь между исполнительной моделью и процессом в натуре, но только в смысле регулирования – запустить остановить предписанное действие, выбрать действие из существующей альтернативы".
    Такой метод действительно в настоящее время является обычным.
    Однако, применимость его в ближайшем будущем вызывает сомнение. Потому что поставлена задача создания электронного общества, т.е. всякого рода нормативные документы, например, документ Регламент предоставления услуги должен быть в электронном виде, но не в виде неструктурированного вордовского документа, а в виде некого структурированного документа из которого естественным образом автоматизированно формируется модель услуги и в соответствии с этой моделью происходит предоставление услуги и други необходимые виды деятельности.

  29. #29
    Член сообщества
    Регистрация
    19.12.2005
    Сообщений
    1,108

    По умолчанию 2 вопроса...

    Цитата Сообщение от algol
    ...Потому что поставлена задача создания электронного общества, т.е. всякого рода нормативные документы, например, документ Регламент предоставления услуги должен быть в электронном виде, но не в виде неструктурированного вордовского документа, а в виде некого структурированного документа из которого естественным образом автоматизированно формируется модель услуги и в соответствии с этой моделью происходит предоставление услуги и други необходимые виды деятельности.
    1. А почему вордовский документ должен быть "неструктурированным"? Может его плохо написали?
    2. Как учить, переобучать, заменять людей, если существует только электронный вид документа "из которого естественным образом автоматизированно формируется модель услуги"? Далеко не все люди хорошо воспринимают текст с экрана.
    С уважением Виталий.
    P.S.
    Болдин писал:
    3. На самом деле, главными результатами проекта являются:
    - Создание базы для регламентации, т.е.: понимания руководителями и сотрудниками что же они все таки делают, накопление и структурирование информационных материалов, пакет согласованных схем процессов.
    - Формирование группы людей которые могут на основе имеющейся информации разработать и согласовать регламенты, и обеспечить их исполнение в дальнейшем.
    Но этого вам никто не скажет...
    Мне однажды это сказали. Причем сказал бывший конкурент на тендере, которому досталась автоматизация БП (мне их описание). Сказал буквально следующее:"Я воспринимал вас как конкурентов, а оказалось, что вы делаете другую работу. После вашей работы мне стало намного легче общаться с заказчиком" (он вел и поддерживал у этого заказчика другие автоматизированные системы расчетов).
    Последний раз редактировалось eliferov; 31.08.2010 в 12:55.

  30. #30
    Член сообщества
    Регистрация
    15.12.2005
    Сообщений
    73

    По умолчанию Два ответа

    1. во первых в тексте написано, что они не должны быть...
    2. есть определенные требования к сотрудникам госуправления, в том числе умение работать с электронными документами. Есть действующий пример в Татарстане, там по другому не работают.

Страница 1 из 4 1234 ПоследняяПоследняя

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •